[box]Carte d’identité

Prénom: Pierre-Antoine
Nom: Grégoire
Age: 36 ans
Nationalité: Française
Fonction: Agile IT Architect
Société: Agile Partner
Loisirs: Photos et musique[/box]

[question]Qui est PAG, l’homme derrière Pierre-Antoine Grégoire ?[/question]

[answer]Je ne vais pas me cacher derrière mon petit doigt, je suis un Geek social, ou geek communiquant.[/answer]

[question]En quoi consiste votre métier? Quelle en est votre approche personnelle ?[/question]

[answer]Apporter mon expertise technique, dans des domaines liés à la conception, au développement, à la maintenance et à l’évolution de systèmes informatiques, en la combinant avec les pratiques agiles et en s’inspirant des principes de l’agilité. Il me semble aujourd’hui utile et nécessaire de pousser l’agilité là elle n’est pas ou n’a pas encore été mise en place de manière intuitive. C’est en effet, une approche qui peut amener des bénéfices tangibles et rapides.[/answer]

[question]Qu’est-ce qui vous passionne le plus dans votre fonction/métier ?[/question]

[answer]Apprendre tous les jours, d’une part techniquement, mais aussi et surtout par les interactions humaines. Je me passionne aussi de plus en plus pour l’amélioration continue des processus de fonctionnement de l’IT.[/answer]

[question]Qu’est-ce qui vous plaît le moins ?[/question]

[answer]Deux points me viennent à l’esprit :

1. Les réunions qui n’apportent pas un retour suffisant par rapport au temps investi :

• si leur durée excède une heure ;
• si le nombre de participants est plus supérieur à 10 ;
• si aucun objectif n’est préalablement fixé.

2.Pour atteindre efficacement les objectifs d’une réunion, je préfère les discussions debout autour d’un un tableau mural, par exemple, facilitant la clarification des propos à celles où chaque participant est assis face à des documents, qui dérivent souvent en monologues juxtaposés.
L’attachement excessif aux processus figés et monolithiques,  qui correspond bien souvent à un manque de confiance sur la capacité des indicateurs de performance à permettre de maîtriser l‘atteinte des objectifs.[/answer]

[question]Qu’aimez-vous challenger ?[/question]

[answer]J’aime challenger le “status quo” des D.I. dans la gestion de leurs systèmes d’informations. En effet une grande partie de ces dernières continuent aujourd’hui à baser la gestion de leur S.I sur des principes historiques et culturels reposant sur des critères d’auditabilité et de reporting qui visent théoriquement l’efficacité du fonctionnement des systèmes. Alors que dans la société actuelle qui évolue de plus en plus vite, la nécessité de répondre rapidement aux besoins des utilisateurs impose la mise en œuvre d’une démarche d’amélioration continue qui doit viser concrètement l’efficacité des équipes.[/answer]

[question]Comment se déroule une de vos journées types ?[/question]

[answer]De manière générale, mes journées débutent par un “Daily stand-up meeting“ qui sert à faire le point sur nos activités de la veille, à exposer les nouvelles activités que nous planifions de réaliser dans la journée, et enfin à donner l’opportunité de mettre en avant les problèmes rencontrés. Ce petit rituel dure au maximum 15 minutes.

Ensuite, la journée peut se dérouler selon trois schémas types :

1. Réalisation d’expertises techniques nécessitant de l’investigation, de l’expérimentation et du codage pour mettre en place la solution à un problème qui nous a été soumis. Cela peut aussi se faire sous forme de workshops.
2. Participation à des réunions avec différents managers afin d’apporter ma vision d’expert et ainsi éclairer les décisions opérationnelles ou stratégiques
3. Participation et animation, le cas échéant, de réunions de bilan (appelées également Rétrospectives) pour décider de la manière d’améliorer notre manière de travailler et d’échanger au sein de notre équipe mais également avec les autres équipes.[/answer]

[question]Comment percevez-vous la place luxembourgeoise ?[/question]

[answer]En réalité, je ne perçois le Luxembourg que par le biais de mes clients et de l’association dans laquelle je suis engagé (i.e.  le YaJUG, Java User Group du Luxembourg).

Ainsi il me semble, que sur la place luxembourgeoise, il y a une réelle volonté d’innovation dans le domaine de l’IT qui se traduit, notamment, par l’ensemble des communautés actives dans ce domaine. En revanche, en dépit cette volonté, il apparait un certain “immobilisme” sur l’application de nouvelles technologies et/ou méthodologies comparativement aux autres pays européens. La nature du marché local, se caractérisant par une forte présence des institutions européennes et financières, n’est sans doute pas étrangère à ce fait.[/answer]

[question]Votre engagement est important dans la Communauté IT luxembourgeoise, notamment au YaJUG. Quelle est votre vision de cette responsabilité sociétale ?[/question]

[answer]Je vois mon rôle au sein du YaJUG comme une contribution à l’engagement de tout un groupe qui a envie de partager des passions communes et d’organiser des rencontres pour se nourrir des expériences des uns et des autres.[/answer]

[question]Que représente l’IT dans votre vie professionnelle ?[/question]

[answer]L’IT constitue le point central de mes activités professionnelles.

En revanche, il me semble de plus en plus évident que la manière d’organiser et de gérer les activités dans ce domaine nécessite d’ajouter une dose d’agilité. Cette partie organisationnelle, si elle est pour l’instant loin d’éclipser ma passion pour les aspects technologiques qui constituent le quotidien de mon domaine d’expertise, prend de plus en plus de place dans la valeur ajoutée que je peux apporter à nos clients.[/answer]

[question]Quels sont vos passions ou vos hobbies ?[/question]

[answer]J’affectionne particulièrement la photographie et la musique. Même si la photographie est plus facile à pratiquer dans le peu de temps libre qu’il me reste, je nourris toujours l’espoir de pouvoir consacrer à nouveau du temps à la musique. Cependant, je suis en définitive assez curieux de tout.[/answer]

[question]Quel est votre endroit préféré au Luxembourg, en dehors de la cantine du CRPHT les jours de YaJUG ?[/question]

[answer]Je passe l’essentiel de mon temps professionnel au Luxembourg, mais je dois admettre que n’y ayant pas passé ma vie d’étudiant ni une vie de célibataire, ma vision de Luxembourg n’est malheureusement pas assez complète pour y avoir un endroit préféré. J’ai toujours eu la volonté de prendre un peu de temps durant la période estivale pour “découvrir” le Luxembourg autrement que par le biais de mon activité professionnelle mais finalement je n’en ai jamais vraiment “pris” le temps.[/answer]

[question]DevOps[/question]

[answer]Le mouvement DevOps, dont nous devons l’acronyme à Patrick Debois, a été initié il y a quelques années. Cette approche, qui vise à combler le fossé entre le déroulement des projets et la mise en production de l’application qui en résulte, me passionne tout particulièrement parce qu’elle met en pratique les techniques agiles aussi bien pour les développements, la gestion de qualité applicative (QA) et l’administration des systèmes.

En fait, là où les pratiques agiles de développement tentent de “briser le mur” existant entre les équipes de développement et le métier ou les utilisateurs finaux, les pratiques DevOps se concentre sur celui qui existe entre les équipes de développement et les équipes opérationnelles et de QA.

Le premier objectif de l’approche DevOps est bien de supprimer le cloisonnement qui existe entre les équipes de développement et les équipes opérationnelles tout en facilitant voire “fluidifiant” les échanges nécessaires au déploiement des versions d’applications livrées par les équipes de développement. S’agissant de déploiement, comme cette approche permet également de prendre en compte ceux réalisées pour les équipes de QA, l’abréviation DevQAOps, bien que non retenue, aurait pu être utilisée.

La mise en œuvre de cette démarche bien que nécessitant l’utilisation de pratiques techniques ne se réduit pas uniquement à leur application comme cela est souvent présenté à tort. En effet, il s’agit plutôt de suivre un processus continu et itératif qui doit aboutir à un décloisonnement entre les équipes métier, de développement, de QA et opérationnelle en travaillant sur deux axes:

• l’optimisation que l’on appellera “locale”, c’est-à-dire au sein de chacune des équipes concernées. Ainsi les équipes métier, de QA et de développement s’organisent pour mieux prendre en compte les besoins opérationnels spécifiques et pour améliorer fortement la qualité des livrables qu’ils doivent fournir, alors que les équipes opérationnels s’arrangent pour offrir une plus grande lisibilité des services qu’ils fournissent et des technologies qu’ils utilisent,
• l’optimisation que l’on qualifiera de “globale” qui vise à mettre en commun les outils et les pratiques mais également à développer une culture de coresponsabilité sur des éléments clés tels que : le déploiement, le monitoring et la mesure de la qualité.

Dans certains cas, il pourra s’avérer profitable d’échanger des ressources au sein des différentes équipes car la finalité est de réussir à mieux les intégrer afin de proposer aux utilisateurs des services à forte valeur ajoutée, réactifs et de qualité. On comprend mieux alors que les dimensions culturelle et organisationnelle jouent un rôle primordial alors que les pratiques techniques servent de moyens à l’atteinte des objectifs. Ces dernières, issues des pratiques agiles, sont de plus en plus complétées de l’utilisation de la virtualisation ou du Cloud computing car il est vrai qu’avec ces services, la promotion des versions d’applications livrées par les équipes de développement pour un déploiement dans un environnement cible (ex : recette, pré-production, production), se trouve grandement facilitée.

Par ailleurs, lorsque l’on applique cette démarche d’autres objectifs tout aussi importants doivent également être considérés :

• la possibilité d’un retour en en arrière (ou rollback) automatisé en cas de problème
• l’utilisation d’outils de mesure du service rendu qui doivent permettre d’évaluer les critères liés à la valeur ajoutée apporté à l’utilisateur
• l’automatisation du suivi aussi bien du service que des activités.

Réussir une telle mutation n’est pas forcément une chose aisée puisqu’elle demande certaines fois de renoncer à ce qui fonctionne déjà, en apportant son lot de craintes et de résistances, au détriment de la nécessité de changement qui devra s’inscrire dans le cadre d’un fort engagement pour une démarche d’amélioration continue. Celle-ci devra permettre notamment de prendre conscience des obligations ci-dessous (qui ne sont bien entendu pas exhaustives) :

1. la transition d’un fonctionnement en mode “push” où le travail est attribué à des équipes, à un mode “pull” où les équipes se saisissent d’un travail préalablement priorisé même de manière grossière;
2. l’acceptation qu’il peut être primordial, à moyen terme, de modifier fortement le mode de fonctionnement des équipes en place en remettant en cause certains critères d’auditabilité.
3. la modification du mode d’évaluation interne qui devra permettre de mieux récompenser ceux qui contribuent à l’amélioration de la prédictibilité du processus complet par rapport à ceux qui atteignent des objectifs chiffrés fixés à l’avance.

Tout ceci ne peut se faire, évidemment, que de manière graduelle comme le prône, par exemple Kanban (une des méthodes agiles dédiée au domaine de l’IT définie par David Anderson) qui permet de mettre en œuvre une démarche d’amélioration continue.

Pour conclure, je dirais qu’une organisation qui se lance dans une démarche DevOps ne pourra en retirer l’ensemble des bénéfices que lorsqu’elle aura atteint l’optimisation “globale”. Ainsi les personnes du métier et de l’IT pourront alors partager le langage ubiquitaire cher aux approches agiles et faire en sorte que l’optimisation devienne une mécanique indispensable, constante et intégrée par tous plutôt qu’un objectif temporaire.

En revanche, ne considérer DevOps que dans sa dimension technique aura pour conséquence de ne pouvoir dépasser le stade de l’optimisation “locale”. Ce qui, en soit, peut constituer une avancée significative puisque les développeurs pourront acquérir une meilleure compréhension de l’environnement opérationnel et à l’inverse les opérationnels une meilleure compréhension de celui de développement.[/answer]