Le terme DevOps cache de nombreux rôles et pratiques différents, qui ne peuvent pas être décrits en une seule phrase. Nous avons interrogé Aleksander Czarnołęski et Michał Piotrowicz de Sollers Consulting sur le thème du travail avec DevOps, ses caractéristiques et le chemin à suivre pour devenir un ingénieur DevOps.
Que signifie DevOps et quel est son rôle dans les projets?
Aleksander: Tout dépend de la définition que l’on donne à DevOps. Le plus souvent, nous rencontrons le rôle d’un ingénieur DevOps, dont l’objectif est d’automatiser le processus de développement de logiciels. Cette approche est partiellement conforme à l’approche globale DevOps, mais elle néglige un aspect culturel et d’organisation des processus crucial – un processus manuel mal conçu, lorsqu’il est automatisé, deviendra un processus automatisé mal conçu.
DevOps est un concept très large qui englobe de nombreuses pratiques. Je les résume généralement par la définition suivante : optimiser le processus de développement et de livraison de logiciels en garantissant une culture organisationnelle, des processus et, en fin de compte, des outils adaptés.
Compte tenu de la perception du marché et de notre expérience en matière de DevOps, nous distinguons généralement deux types de projets :
1. Si nous travaillons sur un seul projet pour un client et que nous avons une influence limitée sur l’ensemble de l’organisation, nous nous concentrons sur la construction du plus haut niveau de maturité et sur l’automatisation du processus de développement au niveau du projet. Cela implique l’optimisation et l’automatisation du processus de développement et de livraison de logiciels, ainsi que la sensibilisation des clients aux pratiques DevOps telles que la collaboration étroite entre les équipes de développement et l’entreprise, les tests précoces, l’habilitation de l’équipe à prendre des décisions, la fourniture à l’équipe d’outils de construction de solutions de bout en bout, etc.
2. Dans les projets visant à transformer l’organisation du client, nous avons un impact beaucoup plus important sur l’établissement d’une culture organisationnelle appropriée et sur la conception de processus au niveau de l’entreprise. Nous essayons de trouver un juste milieu entre fournir aux équipes les bons outils et la liberté de créer, et introduire certains cadres qui permettent de maintenir une approche technologique cohérente, de soutenir la réutilisation des solutions préparées et d’assurer un développement cohérent dans l’ensemble de l’organisation.
Saviez-vous dès le début de votre carrière que vous vouliez être impliqué dans le DevOps ? Comment s’est déroulé votre parcours ?
Le parcours de l’analyste d’entreprise au consultant senior
Aleksander: Mon parcours a été assez atypique puisque j’ai commencé chez Sollers en tant qu’analyste commercial. Au départ, j’étais chargé de rassembler et de créer des exigences fonctionnelles, de contacter des experts du domaine, parfois de préparer des scénarios de test et, plus tard, de les tester. Étant donné que Sollers offre de nombreuses possibilités de développement horizontal au sein de l’entreprise et au-delà du projet en cours, on m’a proposé de coordonner la compétence DevOps au sein de l’entreprise. La tâche consistait à organiser les personnes au sein de la compétence plutôt que de créer moi-même des solutions (à l’époque, je comprenais à peine le concept de DevOps !). Au départ, je ne voyais pas où je pouvais apporter une valeur ajoutée car je n’avais aucune compétence technique.
Ce n’est que plus tard que j’ai compris une définition plus complète de DevOps et que j’ai réalisé que si je me formais correctement et que je comprenais mieux le processus de développement logiciel, je serais en mesure d’aider à construire la bonne culture organisationnelle et à optimiser les processus. J’ai donc commencé à lire de nombreux ouvrages, des présentations et à assister à des sessions de formation. Surtout, j’ai commencé à discuter davantage avec des développeurs, des architectes et des ingénieurs d’infrastructure afin de mieux comprendre leurs routines quotidiennes et les problèmes auxquels ils sont confrontés. Au fur et à mesure que j’ai acquis des connaissances et que j’ai pris la décision stratégique d’investir davantage dans le développement de produits DevOps, ma carrière a commencé à tourner davantage autour de ce domaine. Ensuite, il y a eu des projets où j’ai aidé à construire la culture organisationnelle et à optimiser les processus de développement pour les clients. C’est ainsi que je me suis retrouvé là où je suis aujourd’hui.
Le parcours d’un administrateur informatique à un directeur informatique/responsable DevOps
Michał: J’ai commencé ma carrière en tant qu’administrateur de systèmes et d’infrastructures. Au fil du temps, je me suis davantage impliqué dans des projets externes pour des clients parce que je voulais résoudre les problèmes auxquels mes collègues des équipes de développement étaient confrontés. Auparavant, je rencontrais souvent des commentaires ironiques de la part de collègues commerciaux qui me disaient : “Pourquoi cela ne peut-il pas fonctionner comme pour nous ?” À l’époque, le terme DevOps en était encore à ses débuts, et nous ne savions pas nous-mêmes comment définir nos idées et nos initiatives. La méthodologie agile gagnait en popularité à cette époque, et nous l’avons transposée dans notre travail sur l’infrastructure. Au fur et à mesure que nous menions à bien des projets et résolvions des problèmes, nous avons découvert de nouveaux outils et de nouvelles ressources qui mentionnaient DevOps comme une pratique permettant une livraison efficace des logiciels. Tout cela a renforcé la compétence de DevOps à Sollers.
Rétrospectivement, dans mon cas, le fait d’atteindre le rôle de directeur informatique a été principalement le résultat de deux choses. D’une part, des connaissances techniques associées à une certaine assurance, qui m’ont souvent amené à remettre en question les affirmations du type “c’est impossible”, étonnamment courantes dans le secteur des technologies de l’information. D’autre part, la volonté de travailler en équipe. J’ai rapidement compris que tout dépendait des personnes elles-mêmes et de leur engagement – si nous partageons des objectifs communs, ce qui nous motive et si nous comprenons la valeur de notre travail.
Comment avez-vous atterri chez Sollers? Qu’est-ce que vous appréciez dans ce travail?
Aleksander: Travailler chez Sollers était mon deuxième emploi, que j’ai commencé pendant mes études. J’avais déjà une expérience dans le domaine du recrutement informatique, ce qui a été un bon point de départ car cela m’a permis de mieux comprendre le secteur.
Après quatre années passées ici, j’apprécie la culture organisationnelle horizontale et la possibilité de participer à divers projets et initiatives. J’en suis un exemple, car j’ai commencé en tant qu’analyste, mais j’ai eu l’occasion d’évoluer dans une autre direction. J’ai le sentiment que Sollers se préoccupe de ses employés et qu’il veille à ce que chaque changement améliore véritablement l’environnement de travail. Tous ces changements sont discutés et ne viennent pas du haut vers le bas, mais sont le fruit d’un travail d’équipe. Il est essentiel d’être ouvert au retour d’information. Si un changement suscite de l’insatisfaction, il est examiné et ajusté pour répondre aux besoins réels des employés. Je pense qu’il s’agit d’une bonne approche, car depuis que j’ai commencé (il y a plus de quatre ans), l’entreprise s’est agrandie de plusieurs centaines de personnes.
Il est également important pour moi que Sollers offre de nombreuses possibilités d’intégration, qu’il s’agisse de réunions mensuelles, de voyages de renforcement de l’esprit d’équipe (comme à Malaga ou en Crète) ou de budgets d’intégration que les employés peuvent utiliser pour des sorties communes. Cette année, nous avons fait plusieurs voyages à la montagne, de la voile et des randonnées à vélo à travers l’Europe.
Michał: Pour moi, Sollers a été le premier engagement sérieux après quelques épisodes plus courts dans ma carrière. Ce que j’ai aimé dès le début et qui n’a pas changé à ce jour, c’est le haut niveau d’engagement des personnes et leur ouverture au changement et à l’amélioration continue. Ceci, combiné à la structure plate mentionnée par Aleksander, me permet de poursuivre deux dimensions : soutenir les clients dans des projets de transformation numérique et travailler à mon propre développement et au développement de l’ensemble de l’entreprise. Le développement est l’un des mots clés à Sollers, non seulement dans un contexte commercial, mais aussi d’un point de vue individuel pour les employés qui souhaitent améliorer leurs compétences.
Qu’est-ce qui relie DevOps et Agile?
Aleksander:
La méthode Agile est de plus en plus présente dans pratiquement toutes les entreprises de développement de logiciels. Cependant, d’après nos observations, la plupart des pratiques agiles ne sont mises en œuvre que dans une certaine mesure et seulement dans certaines parties de l’organisation. Il existe même un terme qui illustre cette situation : “water-scrum-fall”, ce qui signifie que les équipes de développement suivent les pratiques agiles, mais que tout ce qui se passe avant le processus de développement (comme la définition des objectifs, la budgétisation, la décomposition des objectifs) et le processus de maintenance qui s’ensuit sont réalisés selon une approche en cascade (Waterfall). Les organisations sont alors désillusionnées par l’approche Agile car, malgré sa mise en œuvre, le rythme de livraison des produits sur le marché ne change pas ou peu.
C’est là que les pratiques DevOps entrent en jeu, en brisant les silos dans le processus de développement et de livraison de logiciels. Elles aident également les équipes de développement à acquérir tous les outils et les compétences nécessaires (à la fois commerciales et techniques) pour être responsables du processus du début à la fin.
Michał: Je suis d’accord avec l’orateur précédent ! L’agilité commerciale ne peut être atteinte sans les fondations appropriées de l’agilité technique. Tant que l’aspect technique de la livraison de logiciels est une contrainte, les entreprises ne réaliseront pas pleinement la valeur commerciale de la mise en œuvre des méthodologies agiles. En mettant en œuvre des pratiques DevOps dans nos projets, nous permettons aux équipes de se concentrer sur ce qui est important, ce qui, à long terme, se traduit par des résultats commerciaux.
Quel avenir pour DevOps?
Michał: Je pense que nous allons continuer à affiner ce qu’est DevOps et la façon dont les organisations comprennent ce concept. Nous constatons déjà une évolution vers une plus grande prise de conscience de l’intérêt d’investir dans une culture DevOps, et le terme lui-même n’est plus seulement un rebranding des opérations informatiques ordinaires. Nos clients ont commencé à reconnaître la valeur de la mise en œuvre des pratiques DevOps en conjonction avec une approche Agile, car ils peuvent obtenir de bien meilleurs résultats non seulement dans le développement de logiciels, mais aussi dans d’autres domaines. Un exemple est le nombre croissant d’offres d’emploi avec différentes variations de “DevOps” – “DataOps”, “SysOps”, “SecOps”, etc. Ces noms représentent la mise en œuvre de pratiques qui visent à apporter de la valeur, à améliorer le travail dans un domaine spécifique et à éliminer les silos des équipes. Le Value Stream Management (VSM) est un autre concept complémentaire au DevOps. Il s’agit d’une technique qui permet d’avoir une vision holistique de la qualité de nos produits et de savoir s’ils répondent aux besoins des utilisateurs finaux. Agile et DevOps se sont principalement concentrés sur une livraison efficace et de bonne qualité technique. La VSM ajoute un autre facteur à cela : analyser si ce que nous créons a de la valeur pour l’utilisateur final.
Aleksander: J’ai le sentiment qu’avec le temps, DevOps et les pratiques qui relèvent de ce terme deviendront une partie naturelle de chaque entreprise qui a quelque chose à voir avec l’informatique (ce qui, à l’époque actuelle, signifie pratiquement toutes les entreprises). Bien sûr, cela nécessite de nombreux processus de transformation qui préparent la culture organisationnelle à un nouveau rythme de travail et à une approche différente de la résolution des problèmes. Je pense que, tout comme il est désormais naturel pour la plupart des entreprises de mener des projets dans un esprit agile, il en ira bientôt de même avec les pratiques DevOps. En raison de la vaste portée de DevOps, je pense que sa mise en œuvre s’entremêlera de plus en plus avec d’autres technologies actuellement cruciales telles que le Cloud, le big data, l’IA ou l’apprentissage automatique. Cela facilitera l’adoption des meilleures pratiques sur le marché et, par conséquent, permettra de développer les méthodes de développement logiciel les plus efficaces.
Aleksander Czarnołęski – Consultant senior chez Sollers Consulting. Il est titulaire d’un diplôme en gestion de l’École d’économie de Varsovie. Depuis près de 5 ans, il met en œuvre des solutions informatiques pour des entreprises internationales du secteur financier. Au cours des trois dernières années, il s’est principalement concentré sur la mise en œuvre de pratiques et d’outils visant à accroître l’efficacité de la livraison de logiciels informatiques selon les approches DevOps et Agile.
Michał Piotrowicz – Responsable informatique chez Sollers Consulting. Il est diplômé de la faculté de cybernétique de l’université militaire de technologie de Varsovie. Pendant 11 ans, il a travaillé sur des projets liés à la mise en œuvre et à l’administration de systèmes informatiques et, au cours des 8 dernières années, il s’est concentré sur l’efficacité des processus de fabrication et la mise en œuvre des pratiques DevOps dans l’informatique.
La source: