Intervention de Albert Benveniste

Le point important, le principal constat, est que les industriels des systèmes critiques – aéronautique, etc. – gèrent les crises avec le même type d'outils que ceux qu'ils utilisent pour concevoir ces systèmes. C'est cela que je vais passer en revue, en vous rendant compte des entretiens que nous avons réalisés avec quelques grands industriels.

Une leçon préliminaire de ces entretiens est que les données constituent une première difficulté. Vous voyez sur ces planches des données très variées qui ont toutes été utiles pour ajuster les modèles épidémiologiques, en particulier les données des opérateurs télécoms, utilisées pour connaître la mobilité des populations. Elles ont aidé à déterminer la compartimentation de modèles compartimentaux SIR et ont permis de comprendre comment les catégories de population devaient être entrées dans les divers compartiments du modèle. Les données Google sont intéressantes en ce qu'elles font apparaître, sur la courbe « travail en présentiel », une plongée deux semaines avant la barre verticale relative à l'utilisation des transports, en anticipation des obligations de confinement. La capacité d'anticipation est un facteur humain qui s'est révélé important. Ceci illustre le fait que le sujet ne se réduit pas à l'obéissance aux règles mais qu'il existe un comportement anticipatif et réactif des populations sur lequel nous reviendrons. D'autres données portent sur les mesures relatives au matériel génétique du virus présent dans les eaux usées et la corrélation qui a pu être établie avec la propagation du virus.

Dans la planche suivante, une courbe montre la chute du taux de positivité des tests intervenue pendant les congés de Noël 2020. C'est juste un artefact dû au comportement de la population qui s'est plus fait tester à cette époque qu'à d'autres. Ceci illustre le fait que l'utilisation brute des données est compliquée et que de nombreux prétraitements sont nécessaires. Ils ne sont pas purement statistiques mais consistent aussi à injecter toutes sortes d'informations latérales. Le processus d'analyse en est donc un peu compliqué.

Passons au point le plus important, c'est-à-dire les résultats des entretiens avec trois grands industriels, Dassault Systèmes, Thalès et IBM, ainsi que deux start-up, CausalityLink et OpenHealth qui est notamment intervenu sur les eaux usées avec le réseau COMETE et les pompiers de Marseille.

Une équipe d'IBM Paris, des anciens d'iLog, a conçu un prototype, développé très rapidement avec des moyens modernes et la technologie « notebook », pour héberger un grand nombre d'algorithmes en explicitant leur enchaînement et en expliquant ce qui est fait.

Cinq parties sont suivies et enchaînées dans ce notebook, depuis l'acquisition des données à partir de sites diffusant des données publiques jusqu'à la représentation de la situation sur une carte pour prédire l'apparition de nouveaux cas dans les départements et planifier les transferts de malades entre hôpitaux, ce point étant l'objet de ce problème d'optimisation en recherche opérationnelle. Pour l'affichage des solutions, l'équipe a simplement utilisé un outil sur étagère, Google Maps, qui est un service Web couramment utilisé pour ce genre de visualisation.

Quels sont les leçons à en tirer ? Le produit final est une application de logistique dont le cœur algorithmique est l'outil d'optimisation CPLEX, développé à l'origine par iLog et maintenant commercialisé et développé par IBM. Cette application utilise de nombreuses techniques logicielles modernes qui permettent la réutilisation de composants algorithmiques préexistants et s'appuient sur de multiples apports du Web pour les données d'entrée et pour les retours ergonomiques, dont la carte.

Il s'agit d'un prototypage rapide, un travail réalisé en un ou deux mois. L'équipe a parfaitement identifié les verrous à lever pour en faire un vrai outil opérationnel. Le premier verrou consiste à réduire le coût de modélisation. Le plus coûteux en algorithmique fondée sur les modèles est la construction du modèle, qui représente typiquement 90 ou 95 % du coût, c'est-à-dire bien plus que le développement du logiciel lui-même. Pour réduire le coût de modélisation, un prototype d'assistant d'aide à la modélisation a été développé, qui a permis de créer un traducteur depuis des règles exprimées en langage naturel vers des contraintes exprimées dans le langage de l'outil CPLEX d'optimisation combinatoire.

Le deuxième verrou est la collecte de l'expertise. L'équipe a esquissé un cahier des charges, avec en particulier la collecte de toutes les règles qu'il faut expliciter pour planifier les transferts. Un transfert ne se fait pas n'importe comment : il existe des règles de nature hospitalière et sanitaire et des contraintes de nature logistique. Il faut donc collecter de nombreuses informations qui viennent de données différentes, ce qui est une difficulté.