Transcription

• Speaker #0

  Bonjour Youssef, merci d'être aujourd'hui avec nous pour le podcast Voice of Industries. Pour commencer, est-ce que tu peux te présenter et nous en dire un peu plus sur ton entreprise Metroscope ?

• Speaker #1

  Bonjour Mathieu, merci pour l'invitation. Je m'appelle Youssef Gouzoul, je suis de formation ingénieur. J'ai commencé avec Metroscope dans l'implémentation de la solution chez nos clients industriels. Et aujourd'hui, je suis responsable des clients en abonnement. Pour Métroscope, c'est une solution logicielle qui permet à nos clients de détecter les problèmes et les défaillances sur les composants, de les comprendre et d'agir dessus. Et pour cela, on exploite l'intelligence artificielle à travers les jumeaux numériques, les algorithmes et le machine learning pour leur permettre de caractériser les défaillances et prendre les bonnes décisions pour agir dessus.

• Speaker #0

  Si je comprends bien, vous êtes dans la maintenance prédictive. Est-ce que tu peux nous en dire un peu plus sur quel type de secteur d'activité utilise vos solutions ?

• Speaker #1

  Métroscope, elle intervient principalement chez les centrales de production d'électricité, à savoir nucléaire, à gaz et aussi la production par biomasse. Et en fait, on va venir appuyer les opérateurs de la maintenance en leur mettant à disposition ce logiciel qui va... les accompagner dans les différentes parties et les différentes phases de résolution des défaillances qu'ils pourraient avoir.

• Speaker #0

  Donc vous êtes dans le monde du logiciel, en particulier SaaS. En quoi la conduite du changement, parce que c'est le sujet qui nous intéresse aujourd'hui, c'est un enjeu chez vos clients ? Tu peux nous en dire un peu plus ?

• Speaker #1

  Ce qu'il faut comprendre quand on parle de logiciel, c'est qu'un logiciel est et restera un objet théorique. et cet objet théorique a été En fait, il s'est intervenu à la suite d'un travail par les équipes pour essayer de comprendre l'environnement. Et du coup, il intègre pas mal de choix, pas mal d'hypothèses. On amène ce logiciel chez nos clients. Donc, il y a toute une partie où il faut comprendre à quel point les hypothèses qui ont été faites au départ sont correspondantes. C'est un enjeu pour nos clients parce qu'eux, ils veulent de la valeur. Donc, il y a eu une décision de venir implémenter une solution logicielle. Parce qu'ils ont identifié une problématique qui méritait un effort et un investissement, et il faut que ça réussisse. Donc ils ont des engagements à la fois envers leur management et envers les responsables financiers pour que la solution soit un succès et qu'elle amène des résultats tangibles pour les équipes de maintenance sur la centrale.

• Speaker #0

  J'imagine que ce sujet de la conduite du changement... C'est arrivé avec vos expériences, donc j'imagine que les premiers projets, les premières implémentations que vous avez pu faire, vous avez pu faire face à ces sujets de conduit du changement. Est-ce que tu peux nous en dire un peu plus et nous dire comment, en fait, déjà nous parler de ce vécu-là et de comment vous avez construit les choses suite à ce vécu ?

• Speaker #1

  Je pense qu'il y avait une chose qu'on n'avait pas bien comprise au départ, et c'est qu'aujourd'hui, dans les environnements industriels, Des expériences de digitalisation, ils en ont connu. Il y a des blessés de guerre. En fait, quand on arrive chez un industriel, on arrive chez quelqu'un qui, peut-être sur les dix dernières années, a tenté d'implémenter de nouveaux outils et en fait, ils ont été confrontés à différentes difficultés. Il y a des promesses qui ont été belles, mais qui n'ont pas été tenues, pour différentes raisons. Et nous, En fait, nos premières expériences d'implémentation, on a découvert un peu sur le tas et un peu sur le tard qu'il fallait intégrer dans notre démarche d'implémentation toute une démarche de conduite du changement depuis le jour 1 pour assurer le succès. Et du coup, quand on arrive au bout de 6 mois d'implémentation où on était très focus sur la partie technique parce qu'on était convaincus de la valeur que ça apportait qu'on était confronté à des difficultés et à des freins que l'on ne comprenait pas, en fait, on est surpris. Mais parce qu'on n'avait pas eu la présence d'esprit de diagnostiquer l'environnement dans lequel on arrivait. C'est un environnement qui est fait d'hommes et de femmes avec une certaine organisation de l'information, une certaine organisation des décisions et du contrôle. Et en fait, on a mené un logiciel qui amène avec lui, comme j'ai dit, des hypothèses, mais en fait une façon de travailler. Donc il vient forcément amener un changement et un déplacement des flux d'informations. Ça c'est un constat qu'on a fait après et du coup on a investi plus tard du temps avec les équipes de nos clients pour redresser la barre. Et ça c'était une de nos premières expériences qui ont été plus ou moins douloureuses et qui nous ont demandé beaucoup de créativité par la suite. Et aujourd'hui, on suppose qu'on aurait pu le faire avec moins d'efforts et en fait, en étant... dans prévoir à la fois les discussions pour faire les diagnostics, définir réellement aujourd'hui comment ils font les choses et quelles sont les contraintes des opérateurs auxquelles on essaie de répondre, et puis d'amener les ajustements qui leur permettent de comprendre pourquoi ils font les choses et comment effectivement elles se font.

• Speaker #0

  Merci pour ces expériences. Effectivement, ce n'est pas toujours évident les premiers projets et puis on découvre. D'ailleurs, je trouve un point hyper intéressant dans ce que tu dis, c'est ... les blessés de guerre. Et en fait, on peut, en tant qu'éditeur de logiciel, puisqu'on est dans la même situation que vous, se retrouver confronté à des clients ou des prospects qui ont eu des mauvaises expériences. Et en fait, qui derrière, achats échaudés, craint l'eau froide. On va dire, pas mal de réticences ou se posent beaucoup de questions dans leur process d'achat parce qu'ils ont été échaudés par ces expériences qui ne se sont pas forcément bien passées. À la fois, peut-être parce que les promesses qui leur avaient été faites étaient trop élevées par rapport à la réalité. Ou tout simplement que le projet s'est confronté à des réalités humaines et terrain qui ont fait que, comme la conduite du changement n'était pas intégrée, ça ne passait pas forcément bien. Tu disais que vous interveniez essentiellement sur des assets critiques. Tu parlais de centrales nucléaires, de centrales thermiques. Donc on est sur des systèmes qui sont quand même critiques de par leur nature, mais également parce qu'ils sont opérés H2477 avec... je dirais, des besoins de disponibilité opérationnelle très élevés. Comment ça impacte, en fait, la culture d'entreprise et la manière dont on va faire la conduite du changement dans ces activités ?

• Speaker #1

  Ces assets critiques, il y a un mot d'ordre, c'est la sécurité. Donc déjà, ils essayent d'assurer en premier lieu la sécurité de toutes leurs activités. Et en fait, ce qui vient avec, c'est la fiabilité des solutions qui leur sont proposées. Ce qu'il faut savoir, c'est qu'ils ont de fait peu de l'altitude par rapport à des erreurs, des choses approximatives, des choses qui demanderaient de venir comprendre un peu plus. Ils cherchent des choses simples, des choses fiables et qui marchent tout le temps. Et donc ces contraintes de ces industries-là s'imposent à eux.

• Speaker #0

  Est-ce qu'on peut dire que quelque part, par nature, ils sont un peu contre le changement ? Ou le changement est quelque chose de complexe et lourd chez eux ?

• Speaker #1

  Je pense que pour ces industries-là, comme pour d'autres, les processus ont été construits sur le long terme. Et on peut parler de rouages qui vont s'usiner sur le long terme pour faire en sorte que la situation bilancielle correspond à celle avec le moins d'efforts possible. Donc ils s'installent dans ces routines-là. Donc quand on amène un outil, en fait, on vient... En quelque sorte, si c'est mal maîtrisé, introduire une impureté. Et donc tout cela crée un stress qui est inhérent au changement parce que ça les amènera peut-être à désapprendre, prendre le temps d'apprendre et puis faire en sorte que ça marche sur le long terme. Cela, ça suppose donc 1. qu'ils aient le temps, 2. qu'ils aient la capacité et surtout qu'ils aient l'envie de le faire. Ce qui se passe trop souvent, même si aujourd'hui on commence à avoir pas mal de recul par rapport à ces situations-là, c'est qu'on amène des solutions qui sont imposées. Donc il y a eu un management qui a été convaincu à un moment, parce que la solution sur papier est pertinente, et elle l'est, mais par contre, ils ne prennent pas le temps, en dehors du quoi, donc le logiciel, de dire le pourquoi et le comment. Et donc ça, les équipes découvrent souvent trop tard les tenants et aboutissants de ce projet-là et qu'est-ce qu'elles essaient de faire. Donc ça, c'est une première chose. Et ce que je disais, c'est que le management également sous-estime le temps supplémentaire qu'il faut prendre à désapprendre et à réapprendre. Et ce temps-là, en fait, il ne se trouve pas, il se trouve rarement parce que ça reste des environnements contraints. donc que tout le temps est maîtrisé donc rajouter on va dire une heure à deux heures par semaine pour suivre les réunions de suivi, comprendre la solution s'il y a besoin, savoir comment ça change tes processus et ta façon de faire. En fait, c'est du temps qui est très important, qu'il faut trouver.

• Speaker #0

  J'imagine en plus qu'ils ont des procédures assez contraignantes de gestion du changement et donc on vient mettre quelque chose de nouveau dans l'organisation, un nouveau système, etc. Ça passe par tout un tas de phases de validation en interne. pour respecter leur procédure de gestion du changement, j'imagine.

• Speaker #1

  C'est sûr qu'en fait, il y a différents types de logiciels. Il y a des logiciels qui viennent sur les chemins critiques et il y a des logiciels qui viennent en accompagnement sur des décisions. Et donc là, certainement, quand tu ramènes le logiciel, il faut opérationnaliser son usage. Et ça veut dire quoi ? Ça veut dire qu'il faut traduire dans le quotidien à quel moment il est utilisé, par qui. Il faut que ça soit dans la main des bonnes personnes. Et après, cette information va alimenter quelle chaîne de décision. Mais tout doit être précisément défini parce que là aussi, il faut assurer la fiabilité, il faut assurer l'efficacité dans le global de ces processus-là, notamment de maintenance sur les centrales. Je vais prendre peut-être un exemple pour rapprocher tout ça. donc là à Metroscope on parle de Donc d'un logiciel d'aide à la décision, l'information qui en ressort c'est une information de, il y a eu une dérive sur un comportement d'un composant, cette dérive implique les défaillances ou les symptômes suivants, mais en fait voilà l'information qui te permet de comprendre la situation. Donc moi je suis opérateur de maintenance, je récupère cette information, donc je suis en capacité déjà de l'analyser, de la comprendre et de me l'approprier. Puis, je suis capable d'écrire un ticket d'intervention pour expliquer la situation et, au vu des éléments, dire c'est quoi les actions qui pourraient être de vérification pour confirmer ce qui s'y passe. Et après, défendre l'action de maintenance auprès des équipes qui vont effectivement le faire. Et donc, si on n'identifie pas la bonne personne, qu'on ne lui donne pas les informations nécessaires pour dire dans quelle instance l'utiliser, et après de dire comment ça va impacter. les décisions de maintenance, en fait, cette solution d'aide à la décision restera l'être morte, parce qu'elle ne s'insérera pas dans un flux de décisions qui permet de prendre des actions.

• Speaker #0

  Très clair. Et aujourd'hui, fort de toute cette expérience, comment est-ce que vous vous y prenez concrètement chez Métroscope pour faire cette conduite du changement et s'assurer que chaque projet soit un succès ?

• Speaker #1

  Aujourd'hui, on a compris l'importance et la centralité de cette question. L'intégrer... En fait, ça commence dès le jour 1. Et moi, j'aime bien la métaphore de la grève d'organes. C'est-à-dire qu'on va passer par toutes les étapes équivalentes d'une grève d'organes. C'est-à-dire un diagnostic de l'entreprise en termes de fonctionnement. Qu'est-ce qu'elles essayent de faire les gens ? C'est quoi les décisions qu'ils prennent ? Où sont les centres d'information ? Quels sont les outils qu'ils utilisent ? Donc ça, ce diagnostic, on essaye de le comprendre. Et en même temps, on essaye de voir... à quel chemin de décision critique la solution vient accompagner, accélérer, améliorer. Donc ça, c'est une première chose. Il y a toute une phase de co-construction où l'idée, c'est, avec les équipes sur le terrain, de dire c'est quoi la meilleure implémentation à faire en termes d'usage, donc qui va l'utiliser, à quel moment, dans quel rituel, pour donner quelle information. Et donc, ça c'est une seconde chose. Et puis, définir des objectifs clairs avec le client. Donc on prend le temps de dire conjointement qu'est-ce qui fera le succès de ces initiatives avec le client. Et là, nous on est certainement, en fait on a une position d'éditeur de logiciels, donc ce qui va nous intéresser, c'est les proxys, en fait les indicateurs clés du type plutôt nombre d'usages, l'utilisateur par semaine. C'est quoi les parties du logiciel qui sont utilisées, et ainsi de suite. Mais en fait, on va traduire ça dans la réalité terrain de notre client, où ce qu'il essaye de faire, c'est de prendre des décisions. Donc, les indicateurs clés partagés de succès seront des indicateurs métiers qui sont liés à combien de décisions ils ont prises sur la base de l'information qui leur a été donnée. Est-ce que ça raccourcit le temps d'identification ? et de résolution de défaillance qu'ils avaient et qui prenaient plus de temps, on suppose, avant. Et puis... quelle a été la sérénité de tout ce processus, parce que là aussi, on essaye d'alléger tout le stress qui est inhérent à ces moments-là. Donc ça, c'est important. Et puis, une fois qu'on a fait le diagnostic, on a défini avec les équipes l'usage qui sera fait, dans quelles conditions, et qu'on a dit ce que c'est le succès, on va suivre dans le temps les indicateurs de succès pour savoir... Est-ce qu'effectivement, on a réussi à le faire ? Et si ce n'est pas le cas, donc on va dire au bout de trois mois, on fait un bilan pour voir quelle est la situation. En fait, on ne s'interdit pas de réajuster. Donc là, ici, il faut avec le client dire qu'on va se ramper parce qu'on a pris le temps de vous comprendre. Mais c'est sûr qu'il y a des décisions informelles qu'on n'a pas vues. des personnes clés, influentes, qu'on n'aura pas identifiées, et qu'au fur et à mesure, on trouvera l'ajustement en termes d'usage qui est le plus adapté à l'environnement qu'on est en train de considérer.

• Speaker #0

  Je te remercie pour ce partage et en particulier sur ces cas concrets. Est-ce qu'on peut conclure par deux, trois recommandations que tu aurais à un industriel qui veut se lancer dans le déploiement d'un logiciel lié à ses opérations pour s'assurer que la conduite du changement se passe bien ? Ce serait quoi les... des quelques key takeaways, comme on dit.

• Speaker #1

  Je pense qu'aujourd'hui, on est vraiment, surtout avec l'arrivée de l'intelligence artificielle, on peut être beaucoup dans le technosolutionnisme. En gros, on dit qu'il y a des solutions logicielles qui ont été bien pensées, qui marchent ailleurs et qui, d'office, pourront marcher chez nous. Il faut ne pas faire l'économie de la conduite du changement, donc en général, et mettre les personnes qui sont concernées par le changement. au centre de cette transformation. Les solutions peuvent être bien belles, mais par contre, si on ne passe pas le temps de savoir réellement qu'est-ce qu'on essaie de résoudre, qui va le faire, et comment évaluer le succès de ces initiatives-là, en fait, elles risquent d'échouer. On en a vu plusieurs, et c'est pour ça qu'aujourd'hui, on voit beaucoup de scepticisme face à des initiatives digitales. Et le meilleur moyen d'y répondre, c'est d'écouter et appliquer sur la base des ajustements qui sont apportés par les personnes, leurs recommandations à eux.

• Speaker #0

  Super. Merci beaucoup Youssef pour ce partage d'expérience.

• Speaker #1

  Merci beaucoup Mathieu pour ton invitation et pour cet échange très agréable.

• Speaker #0

  Merci.