Citation
L'auteur
Pierre-Louis Bescond
(pierre-louis.bescond@roquette.com) - ROQUETTE
Copyright
Déclaration d'intérêts
Financements
Aperçu
Contenu
Le Groupe Roquette est une entreprise française spécialisée dans la production d’ingrédients d’origine végétale pour les industries alimentaires, pharmaceutiques et industrielles. Fondée en 1933, Roquette est aujourd’hui l’un des leaders mondiaux dans son domaine, avec une forte présence internationale et des sites de production répartis sur plusieurs continents. Quelques chiffres-clés :
- 10.000 employés
- 5Mds de CA annuel
- 30 sites dans le monde
- 7 Mt de céréales consommés chaque année (maïs, blé, pomme de terre, pois, cellulose)
En 2018, le groupe Roquette lançait le programme Future Factory. Cette initiative a permis, au fil des ans, d’intégrer de nombreuses technologies innovantes au sein de nos usines. La prépondérance des données, avec plus de 300.000 capteurs pour le pilotage des ateliers, a créé un formidable terreau pour des projets de modélisation et d’optimisation utilisant le Machine Learning.
Pourtant, la mise en œuvre de ces applications a connu, et connaît encore, de nombreux soubresauts, témoignant de la difficulté de passer d’un modèle théorique à une solution robuste et parfaitement intégrée sur le terrain.
J’ai tenté de lister les éléments et circonstances qui peuvent, in fine, déterminer le sort et le succès d’un projet.
Ne pas discuter avec l’Utilisateur Final
Bien que cela puisse sembler un lieu commun, dans un groupe industriel, le processus de décision allant de l’idée d’un projet jusqu’à son lancement implique plusieurs revues successives. Ces revues permettent d’évaluer une opportunité sur de nombreux critères (une quinzaine chez Roquette) et de s’assurer à la fois de la valeur et de la faisabilité a priori du projet.
Souvent, ces projets sont portés par des responsables d’ateliers, qui représentent un échelon intermédiaire entre les instances de décision et les activités sur le terrain. Pour une équipe Data, ces profils semblent avoir une vision complète des problématiques à résoudre.
Cependant, l’expérience a montré que ne pas échanger directement avec l’utilisateur final de la solution dès le premier jour (ex. les opérateurs de production) garantit presque à coup sûr le développement d’une solution qui ne répondra pas parfaitement aux besoins, ou qui traitera une problématique différente de celle attendue par les utilisateurs finaux.
Il nous est même parfois arrivé de constater que l’objectif final de l’application que nous développions n’était pas d’optimiser le pilotage d’un atelier mais de standardiser les pratiques des différentes équipes « sous couvert d’I.A. » ; ce qui s’était avéré difficile via les pratiques managériales classiques.
Forts de ces écueils, nous imposons désormais, dans notre processus Agile, une présentation impérative à l’utilisateur final tous les 15 jours afin de valider en permanence la pertinence de nos développements.
Ne pas tenir compte des Lois Fondamentales
Les modèles de Machine Learning s’appuient essentiellement sur des données collectées afin de reproduire le plus fidèlement possible le comportement d’un processus. Certains phénomènes n’ont jamais été théorisés scientifiquement car ils ne répondent pas à des lois universelles. Par exemple, il existe autant de modèles d’attrition de clients qu’il y a de marchés (et même plus).
Cependant, les processus industriels ont été conçus en s’appuyant sur des lois et modèles issus de la science (lois physiques, chimiques, modèles mécanistiques, etc.).
Chez Roquette, nous avons eu l’occasion de développer des modèles « blancs » (purement issus des équations fondamentales connues), « noirs » (bâtis à partir des données transmises par nos capteurs, souvent appelés « black-box ») ou « gris » (mélange des deux premières options).
Il serait tentant de penser que la bonne instrumentation d’un atelier suffira à comprendre le comportement d’une ligne de fabrication grâce aux données « terrain ».
Cependant, quel que soit le niveau d’instrumentation, certains phénomènes potentiellement impactant seront toujours difficiles à capturer. L’expérience nous a montré que pour atteindre un niveau de performance suffisant, il est nécessaire de combiner ces données « terrain » avec celles issues de la Science. Cela peut se faire en ajoutant des données « synthétiques » pour l’entraînement du modèle ou en intégrant certaines règles « métier » dans la conception de l’outil.
Prenons un exemple pour illustrer cet enjeu : un atelier est majoritairement piloté dans des conditions nominales, voire optimisées ; ce qui empêche d’enregistrer des données correspondant à des conditions extrêmes.
Imaginons un processus qui trouve son point d’équilibre avec un pH de 7 et qu’un dérèglement de ±0,5 le rende instable. Les données collectées, issues d’une production nominale, seront donc toujours centrées autour d’un pH de 7, empêchant l’algorithme de comprendre l’importance critique de ce paramètre.
L’introduction de données synthétiques dans des plages extrêmes, avec leurs conséquences, pourrait permettre à l’algorithme de mieux intégrer cette criticité sans pour autant mettre en péril la production, qui est soumise à des contraintes de rentabilité et ne peut difficilement s’autoriser des écarts volontaires de performance.
Oublier que la valeur du modèle sera évaluée par rapport à un état déjà optimisé
Il n’est pas rare de se confronter à une problématique métier où les responsables n’ont que des intuitions quant au comportement d’un processus. Tout effort de modélisation basé sur des données apportera forcément des indications supplémentaires sur ses mécanismes.
Prenons par exemple la modélisation du risque de départ des employés : les Ressources Humaines en connaissent les facteurs les plus importants (ancienneté dans le poste, perspectives d’évolution, niveau de rémunération, relation avec la hiérarchie ou l’équipe) mais il est très difficile d’apprécier l’impact chiffré de chacune de ces dimensions.
La création d’un modèle permettant de prédire finement le risque de départ d’un collaborateur permet de passer d’une simple intuition à un modèle qui, même imparfait, amène une vraie progression dans la compréhension du phénomène et son optimisation (ex. : prendre des mesures pour prévenir la démission de ressources critiques).
Dans le cas de la modélisation d’un processus industriel, celui-ci a normalement déjà fait l’objet de nombreuses initiatives d’améliorations : analyse des défaillances, maîtrise statistique des procédés… sans oublier l’éventail de techniques apportées par le Lean Management.
La performance du modèle de Machine Learning sera donc comparée à un état déjà fortement optimisé du processus. Sa valeur ne sera établie que s’il permet d’améliorer un fonctionnement souvent déjà proche de la partie « asymptotique » de sa progression.
Il nous est arrivé plusieurs fois qu’un modèle de Machine Learning, construit à partir des données terrain, ne soit pas capable de proposer des optimisations supérieures à celles mises en œuvre par les experts. Les recommandations auraient eu de la valeur si nous n’avions eu aucune connaissance du mode de fonctionnement de l’atelier (cas de figure qui peut se présenter lorsque plusieurs « sachants » ont quitté l’entreprise et que la connaissance s’est étiolée) mais pas dans ces cas où les processus étaient déjà proches de leur optimum.
Plus le processus est critique, plus les recommandations seront difficiles à mettre en œuvre
L’intégration d’une solution utilisant du Machine Learning au sein d’une ligne de production, répondant aux exigences industrielles (robustesse, fiabilité 24h/24 et 7j/7), nécessitera un investissement important. Les vendeurs de solutions vous garantissant une mise en œuvre en moins de 48h sont avant tout des bonimenteurs.
Cet investissement ne peut se justifier que si l’enjeu industriel l’est également. Travailler sur une ligne critique présente alors plusieurs défis :
- La réticence des équipes terrain à tester de nouveaux modes de fonctionnement. Le gain hypothétique et marginal par rapport à une situation optimisée fera peser un risque plus grand sur la performance du processus. En d’autres termes, « Le jeu en vaut-il la chandelle ? »
- Dans le cas de la maintenance prédictive, les lignes critiques font souvent l’objet d’une attention permanente et des plans préventifs garantissent un taux élevé de disponibilité. Les pannes véritablement critiques se produisent de façon très rare et par une combinaison de facteurs qu’aucun algorithme ne pourra aisément anticiper. Plutôt que de chercher à anticiper des pannes qui, par nature, seront exceptionnelles, l’approche pourrait être alors de modéliser le fonctionnement nominal des appareils et d’identifier toute déviation qui sortirait de marges acceptables. C’est une méthodologie que nous avons également testée mais qui s’est confrontée aux réétalonnages réguliers de capteurs prévus par les plans de maintenance qui, à chaque fois, donnaient l’impression au modèle qu’un changement important s’était produit avec une forte criticité. Ces « faux positifs » nous obligeant alors à ré-entraîner le modèle avec une fréquence trop élevée pour, qu’au final, la solution nous permette de détecter quoique ce soit d’intéressant.
De la difficulté d’Intégrer des solutions non-déterministes dans un processus industriel
Les processus Roquette sont soumis à beaucoup de contraintes, directement liées à nos marchés (agro-alimentaire, nutrition et pharmacopée).
Un des principes-clés lors d’audits par les autorités (ANSM, FDA) ou nos clients est notre capacité à démontrer une maîtrise exhaustive des processus qui régissent nos activités.
Intégrer une solution intégrant du Machine Learning pour piloter ou optimiser un process revient à introduire une forme de hasard ; ce qui est justement ce que nous cherchons à éviter.
En effet, la complexité et l’opacité d’un modèle de Machine Learning sont souvent fortement corrélées. On peut « facilement » comprendre l’impact des différents facteurs (Xs) sur la prédiction (Y) d’une régression linéaire puisque les coefficients liés sont connus mais, dans le cas de modèles reposant sur des arbres de décision ou des réseaux de neurones, il est impossible d’en expliquer tous les modes de fonctionnement et réactions. Dans le meilleur des cas, des solutions d’explicabilité (ex. valeurs de Shapley) permettront de proposer une explication « globale » sur le comportement du modèle et parfois une explication « locale » pour chaque prédiction.
Comment l’auditeur peut-il alors certifier la conformité d’un processus lorsqu’un de ces composants échappe à des règles clairement définies ?
Un cas identique s’est posé lors de l’introduction de la maîtrise statistique des procédés (SPC) pour le pilotage de processus critiques. Cependant, ces modèles reposent sur des principes statistiques et mathématiques démontrés et ont un caractère relativement déterministe ; ce qui leur aura permis d’être validés comme une méthodologie approuvée de pilotage. Les algorithmes d’IA que nous utilisons actuellement échappent encore à ce cadre…
Quid de la responsabilité ?
De façon logique, il en est de même pour les questions de sécurité.
Les solutions de Machine Learning peuvent avoir des niveaux d’autonomie assez hétérogènes. Un système pourra émettre des recommandations qui seront analysées puis suivies (ou non) par ses utilisateurs et, dans le cas-là, la responsabilité in fine de toutes les actions reste l’apanage de l’Homme.
Cependant, certaines applications automatisent complètement une partie d’un processus en incluant, par exemple, une forme de prise de décision.
Un exemple récemment mis en œuvre chez Roquette utilise un système de vision assistée par ordinateur pour évaluer le niveau de produit dans une conduite. Si le réseau de neurones considère que le niveau de produit est trop élevé, il déclenche un cycle d’évacuation et de nettoyage (je précise que cette détection ne peut pas se faire par un capteur classique en raison de la nature du produit et de la forme de la conduite).
Cette opération était historiquement confiée à l’opérateur qui devait surveiller de façon très régulière un des écrans dans la salle de contrôle. Cela avait un impact sur sa charge mentale et le forçait à ne pas entreprendre des opérations trop longues dans l’atelier, au risque de ne pas détecter à temps une élévation trop forte du niveau du produit.
Cette conduite fait partie d’un équipement ATEX et il est donc indispensable que les conditions pouvant conduire à une explosion (comburant, combustible sous forme gazeuse ou de poussières, source d’inflammation, confinement) ne soient jamais réunies ; l’évacuation du produit (poudre) devient donc un paramètre critique.
Se pose alors la question de la responsabilité en cas d’incident : cela peut-il être…
- le fournisseur de la solution de Computer Vision (Azure AI Custom Vision) si la détection échoue lors d’un « edge case » (= cas où le fonctionnement de l’algorithme est mis en défaut malgré une performance sur chaque image capturée de 97% et proche de 100% sur un temps long. En effet, si le modèle peut se tromper sur une image, une détection sur un temps plus long (5 minutes) permettra d’avoir la certitude de l’état de la conduite)
- le développeur de la solution ? (qui a créé l’interaction entre les éléments technologiques)
- le responsable de l’atelier ? (qui devrait potentiellement vérifier que le système de détection n’est pas défaillant)
Dans le cas présent, plusieurs solutions redondantes ont été mises en place au niveau technologique :
- alerte si le flux vidéo émanant des caméras est perdu,
- alerte si le système ne détecte aucun « niveau haut » au bout d’une certaine durée,
- alerte si le déclenchement de la séquence de nettoyage n’aboutit pas à la détection d’un conduit vide / propre.
Cependant, il a été décidé que la responsabilité du nettoyage restait du ressort de l’opérateur en charge de l’atelier pendant son poste. Il/elle pourra s’appuyer sur ce nouveau dispositif pour se libérer de certaines contraintes (vérifications moins fréquentes sur les écrans de contrôle, plus de sérénité lors des sorties de la salle de contrôle) mais il était impossible d’exonérer l’opérateur de cette responsabilité lorsque l’on sait que, par conception, les systèmes de vision assistée par ordinateur peuvent être défaillants.
Intégrer de l’IA dans les processus industriels, Mission Impossible ?
On peut donc aisément pourquoi l’implémentation d’une solution de Machine Learning amène un ensemble de contraintes non-négligeables qui n’existent pas nécessairement dans d’autres domaines d’application.
Heureusement, malgré l’ensemble de ces contraintes décrites précédemment, des solutions utilisant de l’I.A. peuvent parfaitement s’intégrer dans des lignes de production, en support aux prises de décision faites par les équipes opérationnelles.
De notre expérience, de telles solutions reposent majoritairement sur des développements logiciels industriels qui ont été testés à grande échelle pour en garantir la robustesse et qui traitent des problématiques « communes » (ex. il sera plus facile d’intégrer une solution vérifiant le port des EPI dans une zone critique que de spécialiser un modèle sur la reconnaissance d’une caractéristique très spécifique d’un produit ; le premier modèle ayant pu être entraîné sur un très grand nombre de cas et d’environnements).
Chez Roquette, les équipes internes ont souvent développés des prototypes afin d’évaluer la capacité d’algorithmes à remplir la mission qui doit leur être confiée… avant de confier l’intégration d’une solution plus pérenne à des cabinets spécialisés.
Cela permet d’avoir un bon compromis entre la validation rapide d’un cas d’usage et la robustesse attendue d’un système plus abouti.