« La logique Ionis-STM, certains l’ont et d’autres pas »
Passé par la filière Informatique & Management, Olivier Camuset (Ionis-STM promo 2014) est aujourd’hui directeur des opérations et des services chez Ascom France. Un poste à responsabilités qui permet à cet Ancien de cultiver ses compétences en gestion de projet et d’équipe tout en touchant à divers domaines, notamment celui de la santé. Et de continuer à appliquer au quotidien « la logique Ionis-STM ».
Olivier Camuset
Ascom se décrit comme « un fournisseur international de solutions de communication et de gestion de flux destinées aux secteurs santé et entreprise ». Qu’est-ce que cela signifie concrètement ?
Olivier Camuset : Ascom est à la fois constructeur et éditeur de logiciels, qui ont pour spécialité d’être destinés aux environnements « critiques » demandant à la fois de la très haute qualité, de la résistance, de la longévité et de l’instantanéité. Cela va de la centrale nucléaire aux usines ATEX, navires offshore, les hôpitaux ou encore les EHPAD.
Pour, par exemple, centraliser les données d’un site ayant une activité assez sensible ?
En fait, nous ne sommes pas sur des outils de métiers liés à la gestion de production ou à la logistique, mais vraiment sur de l’alarme pour des événements. Si l’objectif est généralement de pouvoir tout industrialiser et processer, il reste des événements imprévus, comme à l’hôpital, un secteur où l’on se développe énormément, ou dans l’énergie. Par exemple, le jour où EDF – un de nos clients – a une alarme sur un élément d’un barrage ou d’une centrale, l’entreprise doit pouvoir transmettre l’information à la bonne personne, au bon endroit et au bon moment afin qu’elle puisse prendre en charge le problème. C’est là où les solutions d’Ascom interviennent. Prenons un autre exemple, celui de l’hôpital : en réanimation, un patient peut faire un arrêt cardiaque, s’extuber, etc. Cette problématique doit être remontée au plus vite par l’élément source de l’information. L’esprit d’Ascom est donc de prendre l’événement imprévu, de le collecter à travers des concentrateurs – munis des briques physiques ou logicielles (comme des API) – et de le remonter à une plateforme nourrie de scénarios et d’enseignements pour ensuite le renvoyer sur de la mobilité.
D’où cette double casquette de constructeur-éditeur.
Oui. Mais si nous sommes constructeurs d’infrastructures, nous restons avant tout dans une logique d’ouverture, dans le sens où si un client dispose déjà d’une solution, nous pouvons aussi nous interfacer sur cette solution. Tout est modulaire !
En 2015, vous expliquiez à Ionis-STM votre arrivée au sein d’aXigate, un des leaders français des systèmes d’information hospitaliers, à la suite de votre stage de fin d’études. Depuis, vous avez choisi de rejoindre Ascom. Pour quelle raison ?
Tout simplement par envie d’évoluer. Par mon expérience chez aXigate, je m’étais spécialisé dans la coordination pour le milieu de la santé, au début dans la qualité, puis la gestion de projets et ensuite l’avant-vente. Mon rôle était alors de voir le besoin utilisateur et de le mettre en place. J’étais vraiment sur du service. Et j’avais également pu me spécialiser sur la gestion des alarmes issues des données patient pour créer des réponses de soin et connaître une expérience dans les télécommunications chez un opérateur, dans une relation BtoB. Au final, mon profil était assez cohérent avec les activités d’Ascom, d’autant plus que cette dernière a racheté quelques années plus tôt l’entreprise Italienne UMS qui fait de l’intégration très poussée de dispositifs biomédicaux pour récupérer les données et les alarmes.
Depuis septembre 2020, vous occupez le rôle de directeur des opérations et des services. À quoi ressemble votre quotidien ?
Il consiste à faire beaucoup de choses ! Tout d’abord, avec mon équipe d’experts technique et de chefs de projet, je me dois de coordonner les actions du support client, et d’accompagner nos partenaires sur sites. En effet, nous avons un modèle de ventes majoritairement indirectes, avec un réseau de distribution animé par des partenaires formés et certifiés par l’Ascom Academy. Cette approche est pensée pour que nos partenaires soient le plus autonomes possible et pour que l’on puisse se concentrer principalement sur notre casquette de constructeur-éditeur. Cependant, quand nos solutions sont distribuées, il y a parfois besoin d’une expertise supplémentaire, de niveau 3. Mon rôle consiste alors à vérifier la qualité du support et sa conformité avec le niveau du contrat de maintenance associé (SLA). Une autre facette de mon travail porte sur les projets, quand il convient de mettre en place ce qu’on appelle un « Scope of Work », soit un plan d’assurance qualité, en définissant les contours du projet par rapport aux attentes et besoins du client. Mes services vont ainsi être sollicités par notre pôle commercial afin de sécuriser le résultat final. Pour faire simple, il s’agit de mettre au point une matrice de sécurité en amont du projet.
Auparavant, vous avez été chef de projet. Est-ce la même chose quand on devient « chef de projet des chefs de projet » ?
Non, pas du tout. Certes, il peut y avoir une dimension de « directeur de projet » puisqu’il y a plusieurs chefs de projet – un « client », un « partenaire », un ou deux « internes »… – et, dans ce cas-là, la nécessité de synthétiser et coordonner le besoin peut s’y rapprocher, même si ça demande plus de recul encore. Mais ce rôle-là, qui peut être nécessaire sur très gros projet, n’est plus mon rôle principal. En fait, mon poste actuel tourne essentiellement autour de la gestion d’équipe. Par exemple, si l’un de nos ingénieurs se retrouve dans une situation où il lui manque une certaine compétence, mon rôle est de pouvoir lui apporter l’aide d’un autre ingénieur compétent sur le sujet. Bien entendu, notre but est de pouvoir faire monter en compétences nos collaborateurs pour que le niveau de connaissances soit uniforme, mais on sait aussi que certaines connaissances ne s’acquièrent que par l’expérience. Et quand un ingénieur a déjà fait un déploiement de 4 000 postes sur un CHU avec tels types de routeur, d’infrastructure wifi et d’interface, on sait très bien qu’il peut conseiller un autre et aider à faire remonter des besoins.
Sur votre profil LinkedIn, vous vous décrivez comme passionné par le fait de « faire le lien entre créateurs d’informatique et utilisateurs » et par le « monde de la santé ». À voir votre parcours professionnel, loin d’être linéaire, on serait tenté de rajouter le fait de toujours vouloir évoluer et de ne pas rester figé dans ses positions, ses expériences…
Ne pas être dans sa zone de confort fait partie des choses passionnantes dans le job. Mais dans mon parcours, il y a surtout cette continuité du service, ou plutôt du fait de toujours vouloir proposer un service avec la plus haute qualité possible. Et la qualité, ce n’est pas uniquement la qualité du produit – chez Ascom par exemple, notre culture Suisse nous permet d’avoir des produits très bien conçus – c’est aussi la qualité par rapport à ce qui a été présenté à l’utilisateur final. Cela demande donc d’également réfléchir lors des phases d’appels d’offre avec les clients pour bien statuer sur le besoin et faire la différence entre une petite phrase présent dans un cahier des charges et le besoin réel sur le terrain. Parfois, des précisions sont à apporter et notre expérience nous permet de toucher du doigt ces détails cruciaux. Mon expérience de chef de projet m’a permis de constater que les possibles déceptions étaient quasiment systématiquement liées à des besoins mal qualifiés et définis en amont des deux côtés. Du côté du client, il peut avoir l’impression que la société lui a vendu quelque-chose, mais que concrètement, ce qui est mis en place ne correspond pas exactement à ce que lui attendait, parce qu’il s’était fait une idée de ce que ça allait être. Il vaut donc mieux intervenir en amont de manière structuré, pour éviter tout ça, sur toutes les étapes intermédiaires de réunions d’analyse, de synthèse du besoin, de configuration et de mise en place.
Ce lien entre créateur et utilisateur permet donc d’aider ce dernier à comprendre ses besoins et, surtout, à l’exprimer.
Exactement. Par le passé, en tant que chef de projet pur, j’arrivais parfois trop tard au moment du déploiement de la solution : comme la traduction du besoin avait été mal établie, on se retrouvait dans des situations compliquées, avec des marges réduites du côté de la société et un résultat pas conforme à ce que le client imaginait au départ. Et mon expérience dans l’avant-vente m’a aussi permis de comprendre encore davantage cette notion de service. Parfois, cela passe par le fait d’accompagner le client dans l’évolution de sa façon de travailler, une évolution rendue possible par les nouveaux outils, ou à l’inverse, de devoir adapter le produit car un outil informatique n’a pas à définir la façon de travailler. Un outil doit pouvoir ouvrir de nouvelles portes, pas en fermer.
L’humain doit toujours être au centre, pas l’outil.
Oui. Pour autant, l’outil peut être parfois un bon moyen de s’organiser différemment. Un besoin, ce n’est pas juste de mettre telle couleur ou de placer tel bouton à tel endroit. C’est surtout de répondre rapidement face à telle ou telle situation. Et nous devons à nos clients d’être force de propositions. On doit donc garder en nous cette logique d’ingénieur – on invente, on réfléchit pour construire des solutions – sans oublier ce rôle de traducteur. D’où l’intérêt de pouvoir aussi intégrer l’ingénierie à la phase d’avant-vente. C’est ce qui me permet aujourd’hui de vérifier que les opérations prévues sont, au départ, bien calibrées avant de suivre le déploiement, puis le passage au support et enfin le cycle de vie des produits qui est évolutif. Dans notre domaine, il faut aussi faire avec la disparition de technologies, l’arrivée de nouvelles, la sécurisation, etc… bref être dans l’amélioration continue. Il faut être en mesure de pouvoir faire évoluer la solution sur un temps parfois assez long, bien après son déploiement. Par exemple, dans le cas des produits d’appels malades, les structures téléphoniques vont être placées dans les murs de l’hôpital. Quand un hôpital sort de terre et que nous posons nos briques de communication, il faut que cela puisse durer pendant 20 ans, voire plus ! Il ne faut jamais oublier que ces bâtiments vont, dans leur grande majorité, durer plus longtemps que les modes technologiques.
