En exploitant les mathématiques, l’économie et l’informatique pour aider aux décisions opérationnelles dans l’industrie, la recherche opérationnelle apporte une réelle valeur ajoutée en termes de performances. Thomas Bittar vous explique comment.
Comment optimiser la tournée des véhicules de livraison ? Où implanter les stations de recharge de véhicules électriques ? Comment organiser le fonctionnement d’un atelier pour améliorer l’efficacité de la production ? Pour répondre à toutes ces questions, un seul mot clé : recherche opérationnelle (ou RO pour les intimes) ! Derrière ce nom se cache en réalité un vaste domaine aux applications multiples. L’objectif de cet article est de présenter la démarche à adopter pour traiter un problème de RO.
L’efficience de l’utilisation des ressources dans l’industrie est un facteur important de performance et de compétitivité. En cherchant à résoudre des problèmes de gestion optimale de ressources, les entreprises entrent alors dans le monde de la « recherche opérationnelle ».
Définition et origine de la recherche opérationnelle
Commençons par une définition de la recherche opérationnelle. Elle est définie par la ROADEF (Société Française de Recherche Opérationnelle et d’Aide à la Décision) comme « la mise en œuvre de méthodes scientifiques, essentiellement mathématiques et algorithmiques, en vue de prendre la meilleure décision possible. La RO fournit des outils pour rationaliser, simuler et optimiser l’architecture et le fonctionnement des systèmes industriels et économiques. Elle propose des modèles pour analyser des situations complexes et permet aux décideurs de faire des choix efficaces et robustes » [1].
Autrement dit, la RO fait partie des « aides à la décision » et s’appuie sur des outils mathématiques pour améliorer la performance des systèmes. En sens, c’est une discipline au carrefour des mathématiques, de l’économie et de l’informatique, en lien direct avec l’industrie. Voilà pourquoi elle est « opérationnelle ».
Les mathématiciens à l’origine du concept
La RO trouve ses origines lors de la deuxième guerre mondiale dans les efforts de nombreux mathématiciens pour fournir des techniques d’optimisation des ressources militaires. Parmi eux, Blackett est souvent considéré comme le « fondateur » de la RO, grâce à ses travaux (comme l’implantation optimale de radars de surveillance) mais aussi par la promotion qu’il fait de la discipline auprès de l’Amirauté du Royaume-Uni [2].
L’étendue des problèmes qui entrent dans le cadre de la RO est très large. À titre d’exemple, on peut citer :
- Les problèmes de type « voyageur de commerce », ou comment planifier la tournée d’un véhicule de livraison de manière à minimiser la distance parcourue.
- Les problèmes de type « sac-à-dos », ou comment remplir un conteneur avec des objets de tailles et de valeurs variables, de la manière la plus efficace possible.
- Les problèmes d’ordonnancement, ou comment organiser les tâches sur un chantier de manière à en minimiser la durée, sachant qu’il existe des contraintes de précédence entre les tâches et des contraintes de ressources (humaines et matérielles).
Malgré cette grande diversité, la démarche pour aborder un problème de RO suit certains grands principes.
Les différentes étapes d’un projet de recherche opérationnelle
Les problèmes de RO naissent généralement de problèmes métiers. Comment s’y prendre pour traiter ce type de problème ? Quelles doivent être les qualités d’un spécialiste RO ? Pour répondre à ces questions, nous allons suivre en fil rouge l’exemple d’une entreprise qui cherche à optimiser la maintenance de ses machines.
Définir, en lien avec le métier, les objectifs de son projet
Un projet de RO débute par le recueil des besoins du métier pour définir les objectifs, les contraintes ainsi que les variables de décision du problème. La réussite de cette phase passe par un dialogue entre l’expert RO et le commanditaire (souvent un expert métier). Cette discussion permet alors au commanditaire de préciser ses objectifs, guidés par les questions du spécialiste RO. C’est pourquoi il importe d’avoir une bonne compréhension du métier afin d’extraire de la problématique rencontrée les informations pertinentes nécessaires à la définition du problème.
Dans notre exemple de problème de maintenance, on peut imaginer que l’objectif final du commanditaire soit de réduire les coûts de son appareil de production. D’où la nécessité de comprendre comment sont générés ces coûts. Il peut s’agir de :
- Coûts directement liés à la production (achat de matière première, main d’œuvre, énergie…) ;
- De coûts de maintenance ;
- Ou de coûts supplémentaires générés par la défaillance fortuite d’une machine (liés aux retards de production par exemple).
Ensuite, nous devons définir les contraintes de notre problème. Par exemple : pour des raisons opérationnelles ou réglementaires, la maintenance de chaque machine peut être contrainte à être effectuée dans une fenêtre temporelle donnée. Or la main d’œuvre étant limitée, le nombre de maintenances simultanées doit aussi être limitée.
Enfin, quels sont les leviers d’action inclus dans notre problème ? Ou mathématiquement parlant, quelles sont les variables de décision ? Ici, il s’agit simplement de définir les dates de début de maintenance pour chacune des machines.
L’art de la modélisation
Une fois les objectifs, les contraintes et autres variables de décision établies, vous devez traduire le problème métier en un problème mathématique dans lequel les techniques de résolution algorithmique pourront s’appliquer. C’est la modélisation ! La principale difficulté réside dans le fait de trouver le bon équilibre entre un modèle simple, plus facilement soluble, et un modèle complexe, plus réaliste mais plus difficile à résoudre.
Selon moi, cette étape est la plus difficile d’un problème de recherche opérationnelle. On est ici plus proche de l’art et de l’artisanat que d’une procédure rigoureusement établie. Là encore, des échanges entre experts RO et experts métiers permettent de s’assurer de l’adéquation entre le problème mathématique et les objectifs métier.
Dans notre exemple, il faut commencer par savoir quelles sont les données d’entrée de notre problème :
- Quel est l’horizon de temps de notre problème (1 mois, 1 an, 10 ans…) ?
- Que sait-on sur les défaillances de nos machines ?
- Y a-t-il une loi de fiabilité connue ?
- A-t-on des historiques des pannes ?
- À partir de ces informations, comment modéliser la dynamique de notre système, c’est-à-dire écrire une relation mathématique entre l’état de nos machines (en fonctionnement ou en panne) à un instant t et à un instant t+1 ?
Il faut ensuite faire le lien entre l’état du système et les coûts générés. C’est là qu’intervient le choix de la finesse de modélisation et qu’il est nécessaire de faire un compromis entre réalisme et simplicité de résolution.
- Doit-on prendre en compte un coût fixe lié à l’arrêt et au redémarrage de nos machines ?
- Les durées de maintenance sont-elles déterministes ou aléatoires ?
- Le nombre de maintenances à placer sur l’horizon d’étude est-il fixé ou variable ?
Les réponses à toutes ces questions dépendent des objectifs métiers et des contraintes à respecter, par exemple concernant le temps de résolution. Le spécialiste RO doit donc à la fois avoir une bonne compréhension du métier mais aussi être capable d’analyser la complexité mathématique du problème afin de trouver le bon équilibre dans la modélisation.
Comment choisir un algorithme de résolution et d’implémentation ?
Maintenant que le problème est correctement formulé, nous devons donc le résoudre ! Pour y parvenir, le spécialiste RO va faire appel à ses connaissances en mathématiques appliquées pour proposer un algorithme de résolution. Là encore, il va falloir faire des choix ! Et oui, pour un même modèle, plusieurs méthodes de résolution peuvent être proposées. Leurs différences résident dans la qualité de la solution obtenue, le temps d’exécution ou la simplicité d’implémentation.
Le choix est alors guidé par les objectifs à atteindre : par exemple, privilégie-t-on une solution de très bonne qualité ou a-t-on des contraintes fortes sur le temps de calcul ? Le choix de l’algorithme peut aussi dépendre de la structure du problème : est-il possible de le décomposer en plusieurs sous-problèmes plus simples à résoudre ? Une méthode de décomposition sera souvent plus difficile à mettre en œuvre qu’une méthode directe mais elle permettra de réduire le temps de calcul. Tout est encore une fois une question d’équilibre entre les moyens mis en œuvre et les résultats escomptés.
Méthode métaheuristique vs méthode exacte
Revenons sur notre problème de maintenance. Dans un premier temps, on suppose que le commanditaire nous demande d’implémenter en un temps restreint une méthode dont le but est d’améliorer son planning de maintenance existant, sans nécessairement avoir de garantie d’optimalité. Dans ce cas, il est possible de se tourner vers des métaheuristiques, comme les algorithmes évolutionnaires, qui présentent l’avantage d’être facilement implémentables, mais qui dépendent de nombreux paramètres. Parmi lesquels, le réglage qui nécessite de nombreuses expérimentations.
Maintenant, si le commanditaire accorde plus d’importance à la qualité de la solution (et nous accorde plus de temps sur le projet), il peut être préférable de se tourner vers des méthodes exactes. Selon le contexte, il peut s’agir par exemple de méthodes de séparation et d’évaluation (ou branch-and-bound) intégrées dans la plupart des solveurs. Si le problème présente certaines propriétés structurelles, on peut même envisager la mise en œuvre d’une méthode de décomposition au prix d’un effort d’implémentation plus important.
La validation des résultats
Lorsque le problème est résolu, il est important d’évaluer la pertinence des résultats obtenus. Comment ? En mettant en perspective les sorties de l’algorithme, purement mathématiques, avec le problème réel. Lors des premiers tests, il n’est pas rare d’obtenir des résultats peu convaincants d’un point de vue pratique. Il faut alors détecter les défauts de la modélisation, en identifiant les facteurs les plus influents en regard des objectifs métier. Il est ainsi possible de retoucher progressivement le modèle pour mieux représenter la réalité ou supprimer des éléments qui ont peu d’influence sur le résultat mais qui ajoutent de la complexité au problème.
Même avec des résultats pertinents, prenez soin de toujours veiller à garder en tête qu’ils ont été obtenus par le biais d’une représentation simplifiée de la réalité. Le monde réel est incroyablement plus complexe qu’un modèle mathématique. Bien que l’on obtienne des intuitions, parfois très bonnes, qui permettent de guider la décision, les sorties d’un algorithme ne doivent pas être utilisées telles quelles sans un regard critique. C’est bien pour cela que l’on parle d’outils « d’aide à la décision » et non d’outils de décision.
Conclusion
La gestion optimale des ressources dans l’industrie génère de nombreux problèmes de recherche opérationnelle. Pour traiter ce type de problème, un expert RO doit posséder des connaissances variées, à la fois sur les problématiques métiers, en mathématiques appliquées ou en informatique. Mais en complément, il doit également faire preuve de qualités de communication avec ses différents interlocuteurs.
En exploitant les mathématiques, l’économie et l’informatique pour aider aux décisions opérationnelles dans l’industrie, la RO apporte ainsi une réelle plus-value en termes de performances. Mais les sorties d’un problème de RO étant toujours le fruit d’une modélisation de la réalité, il est indispensable de toujours garder à l’esprit les hypothèses qui ont mené aux résultats obtenus. Objectif : faire les choix pratiques les plus éclairés possibles.
Bibliographie
[1] Le livre blanc de la recherche opérationnelle en France, ROADEF, 2019.
[2] McCloskey, Joseph F. « The Beginnings of Operations Research: 1934-1941 ». Operations Research 35, no 1 (1987): 143‑52.
[3] Introduction à la recherche opérationnelle, Frédéric Meunier, Cours de RO des Ponts.
Vos commentaires
S’il faut de toute façon évaluer la pertinence des résultats et être prêt à revenir sur le modèle pour l’améliorer, ne vaut-il pas mieux adopter une approche agile ? Notamment en commençant intentionnellement de manière très simple, même s’il est évident qu’on va louper des éléments, mais attendre d’obtenir les résultats pour prioriser les prochains éléments à prendre en compte ? L’idée étant de favoriser des cycles courts, plus faciles à organiser, et de s’arrêter quand on obtient un *résultat* satisfaisant… plutôt que de viser un *modèle* satisfaisant dont on spécule sur la qualité des résultats ?
Ou est-ce suffisamment rapide à la base pour ne pas s’imposer d’aller encore plus lentement ?
Merci pour cette brillante et synthétique contribution à la définition de la Recherche Opérationnelle.