Découverte du métier d’ingénieur de production IAM

Je suis ingénieur de production IAM. Mon métier consiste à déployer, maintenir et faire évoluer des solutions de gestion d’identités pour nos différents clients. Concrètement, nos clients ont des systèmes d’information hétérogènes qui se sont construits progressivement selon leurs besoins et qui ont parfois chacun leur façon de gérer leurs identités et leurs droits. Mon rôle est de faire en sorte que toutes ces applications soient alimentées ou dirigées par une seule et même application, de façon à faciliter leur gestion et leur supervision par le client.

Je commence ma semaine par vérifier que tout s’est bien passé le week-end : c’est généralement un moment d’interruption d’activité dans les entreprises durant lequel les traitements les plus lourds sont réalisés. Ensuite, je mène quelques réunions avec nos clients ; notre équipe remonte les points d’attention ou les problèmes, et des décisions sont prises sur les actions et les solutions à mettre en place. Pendant le reste de la semaine, je partage mon temps entre la réponse aux incidents et la mise en place des évolutions de la plate-forme. Voilà pour la description globale. Dans les faits, aucune semaine ne se ressemble justement parce qu’on traite des incidents et des évolutions : chaque problème ou besoin est nouveau et nécessite un traitement spécifique.

L’amélioration perpétuelle de la plate-forme et l’optimisation. Généralement, les gens ont une vision péjorative du support. On nous voit encore trop souvent comme des équipes qui attendent que le téléphone sonne pour régler un problème ou traiter une demande. Je préfère voir les choses différemment. Je pars du principe que moins je suis appelé, mieux je fais mon travail car cela signifie que rien ne dysfonctionne. J’utilise ce temps gagné pour passer en revue ce qui existe déjà et voir comment on peut l’améliorer : optimiser certains traitements pour traiter plus d’informations en moins de temps, revoir un composant qui n’est plus adapté avec l’augmentation de la taille de l’entreprise… Avec ce temps gagné, je peux par exemple mettre en place de nouveaux rapports de sécurité ou de qualité de données qui n’existaient pas jusqu’ici, lesquels peuvent être utilisés par le client pour prendre des décisions opérationnelles ou managériales.

Je dirais qu’il ne faut pas avoir peur d’apprendre. Lorsque j’ai commencé, j’ai été surpris par la quantité de domaines pour lesquels il fallait avoir quelques bases voire même une bonne connaissance pour pouvoir comprendre et effectuer mon travail. Se limiter à certaines compétences est un risque, à la fois pour soi-même mais aussi pour le service rendu aux clients. Pour soi parce que rien ne dit qu’un client ne va pas changer la solution qu’on connait parfaitement pour une autre. Pour le service rendu parce qu’on accepte implicitement de ne pas savoir résoudre des problèmes ou de ne pas être en mesure de proposer des évolutions alors que c’est justement notre rôle. Du côté des compétences nécessaires, je dirais qu’il faut avoir un bon esprit d’analyse et une bonne capacité d’abstraction : les solutions qu’on manipule s’interfaçant avec beaucoup d’autres applications, il faut être capable de prendre du recul pour savoir si une solution dont la mise en place technique semble facile ne va pas avoir d’autres impacts. La connaissance d’au moins un langage de programmation et d’un langage de script est également nécessaire car il faut être capable d’implémenter ce qui a été décidé.

Il ne faut pas être trop sûr de soi. Bien sûr, il n’y a aucun problème à avoir de l’assurance, mais il faut qu’elle soit légitime et basée sur l’expérience et les connaissances. On n’arrive presque jamais dans un environnement où il faut tout construire ; il y a forcément un existant qu’on ne maîtrise pas. Or, notre rôle premier est de permettre à l’existant de continuer à fonctionner sans interruption, les évolutions ne doivent pas mettre cela en péril. Chaque évolution doit donc être réalisée précautionneusement de façon à respecter ce principe. Je dirais aussi qu’il faut savoir remettre en question ce que dit un client. Dans le support, on doit résoudre des problèmes. Parfois, les utilisateurs ont une idée assez précise de la cause potentielle de ceux-ci, mais ils n’ont pas forcément toutes les informations, ont pu mal s’orienter eux-mêmes et nous communiquent parfois de mauvaises données. Se concentrer sur les faits et les informations qu’on a soi-même vérifiés au début est la bonne chose à faire.

C’est un métier plutôt technique, mais les évolutions sont multiples. On peut s’orienter vers de la réalisation de projet, de l’architecture, de l’encadrement d’équipe, de l’avant-vente. Des personnes de mon service ont également changé de spécialité pour en exercer une autre au sein d’Orange Cyberdefense : l’un d’entre nous est par exemple passé de la gestion des identités au SIEM (gestion des évènements de sécurité).