Pour ce premier épisode du ARCAD i Podcast, nous vous proposons de découvrir la jeunesse à l’œuvre dans le monde de l’IBM i au travers de l’interview de Stuart Porlon, Software Developper Engineer chez ARCAD Software.
Nous y évoquons son parcours universitaire quelque peu atypique ainsi que sa découverte de la plateforme IBM i. Nous nous sommes également attardés sur un projet en particulier, qu’il a mené : le projet SCM, chargé de faire la connexion entre Git et ARCAD Skipper.
Écouter l’épisode #01
Stuart Porlon – Bonjour Lucas.
L.K. Est-ce que tu pourrais te présenter ?
S.P. Je suis actuellement développeur ou Product Manager chez ARCAD Software et je travaille principalement sur des produits ayant des problématiques autour de l’IBM i.
L.K. OK donc au quotidien, tu es vraiment un développeur ? Tu es un technicien de la plateforme ?
S.P. Si on parle en termes de technicité, oui et non puisque mes responsabilités ou interventions sont assez larges autant sur la définition des problématiques techniques que sur le suivi et le support au sein des clients, consultants et autres. Donc c’est un périmètre assez large. Mais globalement, je suis assez proche de la technique.
L.K. J’aimerais, pour compléter cette présentation, qu’on puisse parler de ton parcours universitaire, avant d’aborder le professionnel. Tu es quand même relativement jeune, notamment par rapport à l’âge moyen d’un développeur ou d’un ingénieur sur la plateforme IBM i ?
S.P. Oui, effectivement. Concernant mes études, j’ai principalement fait des études assez classiques dans le sens où j’ai fait tout ce qui est classe préparatoire et ensuite une école d’ingé. Et après je me suis orienté plus vers l’informatique, c’est grâce à ça que j’ai eu mon premier contact sur le monde de l’IBM i, notamment grâce à la société OCSI Group. C’est une sorte de pépinière qui propose des formations de trois ou quatre mois autour de l’IBM i et ensuite place ses jeunes diplômés chez différents clients. C’est grâce à ça que j’ai eu ma première opportunité chez ARCAD.
L.K. Intéressant. J’aimerais que tu nous donnes peut-être un peu plus d’indications sur ta formation chez OCSI, de ce que j’ai entendu, comme c’est une formation en pépinière, c’est quand même relativement raccourci. Si je me souviens bien, on est aux alentours de trois ou quatre mois pour la formation ?
S.P. Oui trois ou quatre mois. Et ensuite globalement, ce que l’on fait, c’est déjà découvrir la notion toute première de la plateforme, c’est à dire ce que c’est l’objet et quels sont les premiers langages que l’on est capable d’utiliser sur la plateforme, donc CL et RPG. Et après on extrapole avec les politiques web qui peuvent être rencontrées chez différents clients. Mais durant cette expérience, si je devais faire une simple synthèse, quatre ou trois mois, c’est en tout cas pour des profils qui cherchent comment comprendre comment la plateforme fonctionne. Je pense que c’est suffisant, pas pour développer à un niveau très pointu. Mais en tout cas pour commencer à comprendre l’architecture d’un programme RPG, de comprendre potentiellement ce que c’est et naviguer à travers la plateforme pour faire des premières interventions de types, si je peux dire le support de niveau 1 et 2. Et ça c’est très utile pour pouvoir engranger ou commencer une carrière liée à la plateforme IBM i. Donc en quatre mois on a déjà une petite base suffisante pour s’intégrer dans le milieu professionnel.
L.K. Donc on sent que tu as été assez satisfait par la chose. Tu as anticipé une de mes questions déjà, souvent à titre personnel, j’ai tendance à mettre un peu ce genre de formation en opposition avec les formations plus classiques, plus académiques, qui peuvent être dispensées dans des BUT, les licences et master que l’on peut retrouver dans les différentes universités. J’ai tendance à voir que la formation côté Education Nationale se penche avant tout sur le théorique et ensuite vers une mise en pratique. Là où parfois effectivement les formations type OCSI sont plus courtes dans le temps et nécessitent quand même un certain niveau de connaissances de base si on ne veut pas être largués dès le début ?
S.P. Alors si on doit parler prérequis en termes de profil, un profil qui a déjà compris les principes fondamentaux de la notion de programmation, devrait énormément largement appréhender proprement et correctement le développement au sein de la plateforme. Après, il faut avoir un peu la tête sur les épaules et comprendre les règles de conception associées à la plateforme. Mais globalement, pour une notion RPG, on t’aide à faire un développement en programme RPG, ça devrait être largement suffisant. Donc oui, il y a une différence entre ce qu’on peut retrouver au niveau de l’Education Nationale autour de leurs formations et ce que peut présenter une formation dite « professionnalisante » qui vise en fait directement à aller à l’essentiel du contexte dans lequel on va être amené à évoluer et grâce à ça en fait, de voir et de prendre le temps de voir tous les rudiments et les concepts élémentaires à avoir. Mais encore une fois, je tiens à le rappeler, même si on a eu cette formation de 3 à 4 mois, ça ne veut pas dire qu’on est des cadors sur la plateforme. Ça ne veut pas dire qu’on sait réellement développé et que quand on arrivera sur le marché du travail, on sera capable de tout faire de A à Z. Il reste encore un gap qu’il va falloir effectivement combler. Et il est nécessaire, si je peux dire, de rester humble devant les tâches et d’évoluer petit à petit.
L.K. OK donc une formation très intéressante pour faire le premier pas dans le monde de l’IBM i et derrière se perfectionner à l’ancienne via l’expérience, se perfectionner ?
S.P. Ca va dépendre dans un premier temps, des différentes problématiques que tu vas rencontrer chez des sociétés qui vont te recruter, mais aussi du cadre que l’entreprise va vouloir t’intégrer. Si je peux un peu étendre sur ce sujet, je dirais que pour qu’un profil qui débute dans l’IBM i puisse pleinement s’intégrer, je dirais plutôt que l’accompagnement avec des ressources expertes est le meilleur moyen pour pouvoir intégrer pleinement les nouvelles ressources sur la plateforme.
L.K. C’est un sujet très intéressant, mais je pense qu’on va peut-être se le garder pour un peu plus tard parce qu’on risque un peu de glisser beaucoup par rapport au suivi qui est toi. Je voulais qu’on arrive justement à ton à ton arrivée dans les premières sociétés qui travaillent sur IBM i. On a évoqué ton parcours universitaire académique, on arrive sur ton parcours plus professionnel.
S.P. Comme je l’ai dit avec OCSI qui était la première société à m’embaucher, j’étais en prestation au sein d’ARCAD Software. Et c’est à partir de là que j’ai réellement commencé mes premiers développements dans le monde professionnel, en tout cas relatifs à la plateforme IBM i. Donc jusqu’à présent, ça fait à peu près six sept ans que je suis chez ARCAD, et je ne cesse aujourd’hui de rencontrer des problématiques relatifs à l’IBM i et autres, qui drivent un peu mon ma carrière.
L.K. On a évoqué ton arrivée chez ARCAD, depuis plus de cinq ans, je pense que tu as eu le temps de voir pas mal de choses. Quel projet t’a le plus marqué ? En quoi ça consistait ? Comment est-ce que tu as réussi à t’en sortir ? Et par rapport à la plateforme, qu’est-ce qui était intéressant à voir ?
S.P. Le projet aujourd’hui qui m’a plus marqué, ça a été l’implantation du module technique chinois qu’on appelle ARCAD SM, qui en fait est une technologie qui relie le produit ARCAD Skipper, livré par ARCAD et GIT. Juste pour info, ARCAD Skipper est un module technique qui permet de gérer des composants d’une application mais en version uniquement Legacy, applicative, donc il n’y a pas d’interface. C’est uniquement un composant technique qui se charge et qui est visible depuis RDi ou les interfaces 5250. Mais il n’y a pas cette connexion avec le monde extérieur, notamment GIT quand il a été présenté comme étant la référence en termes de management de code source. Donc ARCAD SM répond simplement à cette objectif.
L.K. Donc si je comprends bien, le but du jeu, c’était que le gestionnaire de code maison qui est adapté à l’IBM i puisse être replacé dans le cadre plus général des gestionnaires de code en s’associant à GIT ?
S.P. C’est bien ça. Et en fait plus on avançait sur l’offre que présente ARCAD par rapport à ce type de technologie, plus je me suis retrouvé à avoir mes premières interactions clients en frontal. Mes premiers challenges pour pouvoir maturer la solution afin qu’elle puisse répondre aux exigences en terme d’implémentation chez différents clients. Mes premiers contacts avec le marché américain et leur vision de ce que c’est ou de comment ils consomment de la technologie de manière générale. Et tout a été, si je puis dire, mes premières fois avec ce type de produit.
L.K. Tu disais juste à l’instant que, par exemple, les Américains avaient une manière de consommer différente, c’est à dire que dans la manière même de travailler aux États-Unis, enfin, de manière générale, Amérique, Europe, Asie ou quoi que ce soit, tu as dû revoir le produit parce qu’il y avait plusieurs usages différents ?
S.P. Au final, tout ce que les clients cherchent à obtenir, ce sont des produits qui fonctionnent dès que tu l’installes et que tu consommes la technologie, ça fonctionne. Mais je n’avais pas cette vision là dans mes années précédentes, puisque j’étais un peu couvert, puisqu’on me déléguait pas mal de travail ou de développement à faire mais sans avoir une exposition concrète et réelle sur le marché. Et c’est grâce au marché américain que tu comprends l’exigence qu’un éditeur possède lorsqu’il livre sa solution sur un marché. Et de manière générale, quand je parle de différence entre les Américains ou d’autres d’autres marchés, c’est simplement sur la tolérance qui s’ensuit. Chez les Américains, on est plus sur « quand j’installe ton produit sans avoir besoin de toucher en sortant certains aspects de paramétrage de ton technologie, ça doit fonctionner. ». C’est la promesse que tu as que tu offres. Alors que sur des marchés un peu français ou européens, on peut être amené à adapter à la volée sur certains aspects sans pour autant dégrader proprement ton produit. Et c’est la différence qui existe et qui m’est restée en tout cas sur les premières implantations d’une telle techno.
L.K. Donc tu as pu voir que tu as dû faire des modifications par exemple en live de l’implémentation que tu étais en train de faire de ton module SCM pour qu’il puisse s’adapter à des contraintes spécifiques en France ?
S.P. Disons que dans le cadre d’un tel projet, il n’y a pas seulement l’aspect technique pour pour pouvoir livrer ce concept, mais aussi toute la méthodologie et dans le cadre de GIT, c’est très marquant. Et chez certains clients européens, en changeant la méthodologie, en adaptant la méthodologie, on pouvait rentrer dans un moule qui permettait de répondre au besoin. Alors que chez les Américains, c’est un peu plus complexe. En fait, c’était la solution en elle-même qui était sujette à évolution afin de pouvoir répondre aux exigences demandées. Mais bon, dans tous les cas, ça a été bénéfique, autant pour moi que pour ce type de produits, car la maturité, la vision de produit ne fait que que se développer.
L.K. Donc quelque part c’est une amélioration continue. Donc j’ai envie de te demander, de ton amélioration continue depuis que tu as commencé ce projet, depuis que tu l’as mis en place, qu’est-ce que tu retiens au final ? On a parlé de ce qui t’a marqué, mais qu’est-ce que tu en a retenu en terme professionnel ?
S.P. En terme professionnel, je pourrais dire que le premier point, c’est comment ton client utilise réellement ton produit, et quelles sont finalement réellement les attentes qu’il en ressort. Pas en termes de livraison mais en termes d’utilisation. Est-ce que ta technologie est suffisamment simple d’utilisation afin d’avoir en fait des temps de mise en production pertinents ou d’adoption même de technologies les plus pertinentes ? Le deuxième point aussi, sur tout ce qui est vision produit. On a tendance, sur mes premières années, j’étais plutôt pour me dire sur des problématiques où on visait simplement à concevoir des développements à un but assez limité. Là, dans ce type de projets, on est plus sur une vision du produit et qui dit produit dit process, qui dit process dit multitude de composants et donc d’être capable de développer une base de règles ou de méthodologie sur laquelle tous tes composants vont pouvoir être traités de la même manière. Et après, tu as aussi toute la méthodologie qui s’en suit. Qu’est-ce GIT ? Comment l’utiliser ? Comment notre offre peut répondre à cette dernière ? Et quelles sont les améliorations qu’on peut obtenir ? En fait, c’est tout ça qui contribue à changer ta vision et à t’améliorer en tant que développeur.
L.K. Donc ça a été total, tu as vraiment eu quelque part le package complet ?
S.P. Oui effectivement. Surtout quand la connaissance de GIT sur la plateforme IBM i, dans l’écosystème, n’était pas aussi mature que ce qu’elle est aujourd’hui, sur les premières implantations, tu te demandes est-ce que c’est toi qui est en erreur ou est-ce que c’est GIT a une spécification, une particularité. En tout cas tu as quelques quelques moments où tu te remets vraiment en question.
L.K. Les idées noires qui viennent te bouffer la nuit un peu ?
S.P. Ben je dirais pas ça, mais je dirais que ça devient exigeant parce que tu te demandes si c’est dans la conception de ton de ton produit ou dans l’offre que tu proposes ? Est-ce que c’est c’est toi qui fait une erreur d’architecture ou est-ce que c’est simplement un aspect que tu n’as pas soit réellement pris en compte mais qui en fait une implémentation assez facile des choses. C’est plus ça qui est qui fait le grand saut quoi. Et encore une fois, je le répète, c’est vraiment après le marché. C’était mes premiers contacts réels avec des utilisateurs en frontal et donc je dirais que entre leur calendrier de mise en production et lorsque ils t’appellent et que derrière les temps de résolution sont assez courts, il a fallu trouver les bonnes solutions.
L.K. Ça y est, ça a l’air de marcher, C’est bon, les périodes de remise en question sont sont derrière toi maintenant ? En tout cas, en tout cas sur sur le module SCM ?
S.P. Alors on peut faire une digression. Tout produit de manière générale peu importe la société, tout produit n’est jamais fini. Il y a toujours des axes d’amélioration qui sont à explorer ou à réaliser. Et c’est le cas pour le projet SCM. Donc je dirais simplement qu’on a passé une phase qui a permis de rendre ce produit là robuste et ensuite en fonction de l’évolution du marché, en fonction de l’offre qu’on peut être capable d’apporter, ce produit, comme tout produit va encore grandir, encore maturer et gratter des parts de marché.
L.K. Mais on peut espérer. On avait évoqué au début de ce podcast, ta jeunesse relative par rapport à l’âge moyen, notamment des développeurs de la plateforme IBM et notamment comment ça a pu jouer dans tes expériences chez ARCAD. Est-ce que tu pourrais donner ton âge exact, s’il te plaît ?
S.P. 30 ans
L.K. Alors voilà, si je ne dis pas de bêtises, l’âge moyen d’un développeur IBM i se situe plutôt autour des 45 ans, voire 50. Donc ça fait quoi d’arriver dans un monde où tu te dis mince, il y a des gens, c’est un peu des papas en face de moi. Et sur une technologie en plus assez particulière, je pensais avant d’avoir des premiers contacts avec OCSI ça a dû être encore quelque chose à part ?
S.P. C’est vrai que c’est assez particulier lorsqu’on présente la plateforme et qu’on te dit que les acteurs que tu veux avoir, en tout cas, tes collègues sont des gens qui ont déjà bien 45 ans, voire plus. C’est là où tu prends conscience de la discontinuité générationnelle qu’il y a entre cette génération qui a évolué à travers la plateforme et cette nouvelle nouvelle génération qui trouve les opportunités à travers cette plateforme là. Mais en soi, en tout cas, lorsque j’étais chez ARCAD, ça n’a pas été un problème. Au contraire, je pense que c’est même une force. Pourquoi ? Tout simplement parce que, en fait, plus tu côtoies des profils seniors, plus tu as le souci du détail et plus l’expérience qu’ils ont acquise durant toutes ces années, tu en bénéficies dans les cinq premières années de ta carrière. De mon point de vue, la connaissance que tu accumules en se basant sur l’expérience qu’ils ont eue et la manière dont tu peux la réutiliser pour produire ensuite derrière ta propre carrière, c’est une sorte de booster des carrières qui permet à certains jeunes de prendre des opportunités en termes de postes, de problématiques techniques, que ce que d’autres où tu aurais eu un déroulement de carrière un peu plus long en terme d’opportunités.
L.K. La question sous-jacente dans ce cas là, c’est la transmission de connaissances de manière générale. Comment est-ce que tu as réussi quelque part à organiser ce passage de connaissances ou comment est-ce que tes collègues plus âgés ont réussi à organiser le passage, le transfert de connaissances pour que tu sois bien intégré, que tu puisses vraiment réussir ta montée en capacité ?
S.P. Je pense que c’est des deux côtés. Le profil seniors entreprises doivent mettre en place un cadre et un contexte dans lequel ils peuvent faire un transfert de compétences. Notamment « comment développer sur la plateforme », « quelles sont les particularités de la plateforme dans la programmation », « la finesse de programmation ou du développement que l’on peut être amené à rencontrer » et qui est typiquement associé spécifique à l’IBM i, et à toi en tant que nouvelle ressource, où tu te dois d’avoir une posture d’écoute. Où tu es est encore en apprentissage et ce n’est pas parce qu’on a la fougue de la jeunesse.
L.K. Qu’on peut aller balayer d’un revers tout ce qui a été fait avant.
S.P. Exactement. Et il y a des connaissances qu’on ne voit pas dans le cadre de formation, ou même sur certaines sociétés qui, à chaque fois que tu changes de boîte ou que tu as d’autres opportunités, tu découvres de nouveaux aspect de la plateforme. Si je devais simplement résumer, je dirais une posture d’écoute et d’humilité de la part de la nouvelle ressource, du jeune, et ensuite une volonté de pouvoir transmettre l’expérience de la part des seniors.
L.K. Ça, c’est intéressant. C’est une synergie ?
S.P. Exactement. Et quant tu as ça, et quand cette synergie fonctionne bien et qu’elle est qu’elle est productive, la valeur, du jeune ou du senior, est uniquement favorable pour la société. Et c’est comme ça que tu réussis ton transfert ou ton renouvellement de génération sur ce type de poste.
L.K. Je vais me permettre un parallèle avec le monde du football parce que ce que tu racontes, ça me rappelle beaucoup la phrase, une sorte de Monsieur Denoueix quand il était entraîneur à Nantes durant les grandes années de Nantes. Pour ceux qui nous écoutent et qui aiment bien le football, il disait que « Un bon joueur, ça coûte cher. Un deuxième joueur, ça peut coûter au moins tout aussi cher. Mais que c’est la relation entre les deux qui est complètement inestimable. » Est-ce qu’on ne serait pas un peu sur le même schéma de pensée ?
S.P. Je pense que cette citation a du sens.
L.K. Avant de conclure ce podcast, j’aimerais te laisser si tu le sens, une espèce d’antenne libre. Est-ce qu’il y a un sujet en particulier, toujours sur IBM i, qui te tient à cœur quand au quotidien tu travailles sur la plateforme ? Est-ce qu’il y a un sujet sur lequel tu aimerais insister ?
S.P. Alors j’aurais simplement quelques messages pour les profils juniors qui vont arriver ou qui sont déjà présents. Moi je leur dis que sur la plateforme IBM i notamment avec cette problématique de renouvellement de ressources pour qu’ils comprennent la plateforme, il y a que des opportunités qui vont s’ouvrir. Et en termes de position, en termes de carrière, et si je me trompe pas quand on regarde certains articles autour de personnes qui gravitent autour de de l’écosystème IBM i, tu vois que tu as des jeunes qui sont à peu près cinq ans dans une boite et qui rêvent en fait à avoir des postes de directeur rapidement. Ce sont des des opportunités où tu ne vois pas ça sur d’autres plateformes
L.K. La plateforme IBM i propose des opportunités pour les nouveaux, n’hésitez pas, allez-y c’est ouvert ?
S.P. C’est exactement ça. En fait tu peux faire des sauts parce que l’opportunité se présente à cause des problématiques que l’on rencontre en terme de ressources. Donc il faut savoir les saisir ces opportunités là. Et je pense que les plateforme IBM i permet de faire ce type de de bond. Le deuxième point concerne les profils seniors, les entreprises qui intègrent de nouveaux profils débutants autour de la plateforme IBM i, c’est d’être patient avec les jeunes profils qui rentrent dans l’IBM i. On peut réussir un transfert de compétences que si et seulement si on se donne la patience de donner le bénéfice du doute à la ressource, de pouvoir pleinement s’intégrer dans l’écosystème existant.
L.K. Ca fait un peu message de tolérance en quelque sorte envers la jeunesse. Il va y avoir quelques chutes, quelques égratignures en quelque sorte le temps d’apprendre, mais ça va prendre un certain temps derrière mais ça va se faire. C’est ça ?
S.P. Encore une fois, on peut pas demander à un junior d’être entièrement bon dès ses premiers mois. Il y a un temps d’apprentissage et notamment lorsqu’on parle d’un profil IBM i, on n’est pas uniquement sur un profil de développeurs, on est aussi sur quelqu’un qui comprend la plateforme, sa subtilité. Qui comprend effectivement qu’en utilisant telle instruction, il y a une telle différence sur la manière dont la plateforme va la comprendre, les avantages d’une telle instruction. Et du coup, c’est toute cette connaissance, cette transmission d’informations qu’il faut donner. OK, il faut donner la patience à la jeune recrue, d’absorber pour ensuite être capable d’exploiter au moment venu. Donc patience pour les entreprises qui intègrent de nouvelles recrues.
Notre présentateur
Lucas Kleinmann
Software Development Engineer
Ingénieur logiciel, Lucas Kleinmann est un amoureux de l’IBM i dans toute sa moderne splendeur.
Pas de titre grandiose ou d’expérience digne d’un grand sage. Juste de l’amour pour une plateforme en pleine mue.