Avec le développement exponentiel de l’informatique Cloud des dernières années, notre capacité d’hébergement a explosé; passant de quelques machines virtuelles à des serveurs complets contenant toute l’infrastructure nécessaire pour le développement de logiciels et d’interfaces clients. En réaction à cet immense potentiel, les développeurs·euses s’efforcent de mieux comprendre l’environnement infrastructurel dans lequel leurs logiciels évoluent, et même de participer à sa conception. En tandem, les opérateurs·trices TI empruntent de plus en plus de concepts au développement de logiciel pour déployer et maintenir leurs infrastructures virtuelles, créant un nouveau croisement entre le développement de logiciels et les opérations TI qui ne cesse de croître. Ainsi, un recueil des meilleures pratiques prend forme : le DevOps.

Alors, c’est quoi au juste le DevOps?

C’est intéressant de constater que ni Pierre-Antoine Développeur CloudOps chez Officevibe, ni Yohan Belval, DevOps Lead et Développeur Full-Stack chez ShareGate, ne considèrent leur rôle comme étant axé sur le DevOps. En contraste avec d'autres méthodes Agiles caractérisées par une structure assez réglementée, le DevOps se démarque en étant très flexible et modulaire. En fait, Yohan évite même d’utiliser le terme DevOps s’il le peut. Il considère que chaque principe devrait être étudié individuellement pour évaluer s’il peut réellement avoir un effet positif sur son équipe, ou si son introduction ne ferait qu’ajouter une complexité inutile au cycle de développement.

« Ma job se résume par spécialiste Cloud, et non pas spécialiste DevOps . Pour nous, c'est une mentalité, pas un rôle. Les équipes travaillent en mode DevOps plutôt qu’avoir un ou deux développeurs spécialisés dans cette approche. Comme ça, on peut pousser plus loin sur l’itération rapide et autres concepts. »

Pierre-Antoine Deshaies
Développeur CloudOps chez Officevibe, Workleap

S’il n’y a donc pas de définition catégorique du DevOps, on peut au moins dire qu’à sa base, tout principe DevOps cherche à optimiser et à fiabiliser les outils avec lesquels un produit est livré et soutenu. On peut intégrer ces méthodologies de façon radicale et intégrale, comme l’a fait l’équipe Officevibe de Pierre-Antoine, qui est passée d’un cycle de mises à jour aux deux semaines à un système de déploiement continu, regroupant des méthodologies d’itération rapide, de micro-optimisation et micro-expérience, et de feature flags qui lui permettent de déployer son code sur un plan compté en minutes plutôt qu’en jours. Le tout, sans même augmenter le niveau de risque vis-à-vis de la stabilité ou de la sécurité du logiciel.

Mais, pour ceux qui préfèrent y aller de façon plus mesurée, l’intégration peut être ciblée là où elle va avoir le plus d’impact, comme Yohan et ShareGate l’ont fait en mettant l’accent sur des procédures d’automatisation et d’évaluation qui soutiennent un cycle de développement un peu plus standard.

Qui se lancerait en DevOps?

Selon la logique d’une méthodologie modulaire, il n’existe pas nécessairement de profil exact pour celui ou celle qui cherche à mener son équipe dans une transition DevOps. Chez Workleap, on attaque la chose d’un angle plus axé sur le développement, vu nos forces, mais un expert TI peut être aussi bien placé pour ce faire.

L’important pour quiconque aimerait se lancer en DevOps? Avoir une approche de « personne à tout faire » et savoir voir plus loin que sa propre spécialité, puisque le DevOps demande une certaine agilité tant en développement qu’en déploiement, en configuration et en évaluation de performance.

3 conseils de Yohan pour de futur·e·s DevOps Leads

1. Il faut avoir de l’intérêt pour l’infrastructure. Bien des développeurs·euses ne s’y intéressent pas, alors démarque-toi par ta passion.

2. Choisis ta plateforme. Pour Workleap, la solution a été Microsoft Azure, mais assure-toi d’être très à l'aise avec la plateforme de ton organisation.

3. Une fois que tu connais un peu le terrain, c’est le temps de te lancer dans le « développement qui est tout sauf du développement » : l’infrastructure, les configurations et les protocoles web/de sécurité qui créent la base de soutien pour ton produit.

Le parcours de Yohan démontre bien cette curiosité. Passé d’une carrière en génie électrique au développement de logiciels, il est devenu l’expert Microsoft SharePoint de Workleap. Familier avec tout ce qui est base de données et infrastructure Cloud, le rôle de DevOps Lead semblait avoir été fait sur mesure pour lui.

Du côté de Pierre-Antoine, Officevibe cherchait un candidat pour combler un rôle principal au sein de l'équipe des CloudOps depuis déjà un an lorsqu’il a posé sa candidature. Jeune recrue qu’il était, il démontrait un intérêt marqué pour l’infrastructure virtuelle, et les membres de son équipe lui ont donné la chance d’évoluer dans ses responsabilités. Il a récompensé cette confiance en prenant sa place au cœur de leur transition DevOps.

Bien qu’ils abordent leurs tâches sous des perspectives très différentes, Yohan et Pierre-Antoine restent en accord sur leur mission principale : intégrer uniquement les meilleures pratiques qui peuvent être adaptées aux besoins de leur équipe, et pas simplement parce que c’est la nouvelle tendance dans le monde du développement.

Quand le DevOps devient-il pertinent?

« Le bateau coulait et tout le monde s’est mis à en écoper l’eau en panique. On s’en est sorti, mais c’est là qu’on a eu la réflexion de mettre en place les processus pour s’assurer qu’on n’en revienne jamais à ce point », confie Pierre-Antoine.

Ils l’ont surnommé le Perfect Storm. Officevibe, son équipe et son logiciel, avaient franchi le point de non-retour. La performance du produit était mauvaise, le cycle de développement tardait de plus en plus et même les fondateurs de Workleap passaient de temps en temps pour partager leurs craintes. Le coup de grâce : un ultimatum de notre plus gros client. Si on ne réglait pas nos affaires d’ici hier, notre partenariat prendrait fin.

Disons que ce n’est pas la méthode de transition vers le DevOps qu’on vous conseille, mais ce Perfect Storm fut aussi un moment parfait pour réévaluer et renouveler nos opérations de fond en comble. Notre cycle de mises à jour causait toutes sortes d’embouteillages pour nos équipes de développement et d’assurance de la qualité, alors on a mis en place un cycle de déploiement continu. Pour assurer la fiabilité de notre code et réduire l’impact des changements sur nos clients, on a instauré une séquence de feature flags pour déployer nos mises à jour sur des environnements de test de plus en plus larges (Eh oui, Workleap a toujours de l’appétit pour le dogfooding!). Aujourd’hui, par exemple, des systèmes d’évaluation automatisés nous envoient des alertes instantanées dès qu’un de nos services dépasse son quota de performance. Ce n’est qu’un exemple parmi tant d’autres, mais, pour finir, ce renouvellement radical de nos méthodologies nous a permis de naviguer entre les écueils d’un Perfect Storm potentiel, tout en versant des dividendes par rapport à tout ce qui concerne notre vitesse de développement et la sécurité de notre produit.

Cependant, la transition DevOps ne fait pas obligatoirement partie d’un aussi grand changement de cap. Le projet interne qui deviendrait éventuellement ShareGate Apricot a été lancé avec un modèle de développement assez traditionnel et, même aujourd’hui, l’équipe de Yohan conserve son calendrier de mises à jour régulières aux deux semaines.

« En général, c’est une erreur de lancer un projet avec une méthodologie trop compliquée. On préfère commencer simple et mettre l’accent sur le logiciel, attendre que la base de clients se développe et, par après, utiliser les ressources acquises pour investir dans nos opérations. »

Yohan Belval
DevOps Lead & Développeur Full-Stack chez ShareGate, Workleap

Soyons clairs : ce n’est pas que l’équipe ShareGate est indifférente envers le DevOps. Ses membres se fient autant à la télémétrie de performance que ceux de l’équipe d’Officevibe pour éviter de tomber dans un même piège. C’est aussi une équipe qui se penche sur l’automatisation de la création d’infrastructure, se fiant à des configurations codées, au lieu de tout faire à la main afin d’épargner une quantité inestimable de ressources lorsqu’il y a une erreur ou un bris du système.

Par contre, ces équipes ne vont pas se lancer dans une nouvelle méthodologie simplement parce qu’elle existe. Éventuellement, elles aussi veulent passer vers une structure de petites équipes mieux placées pour profiter du développement continu et d’autres pratiques DevOps. Mais ce sera fait selon l’échéancier qui convient à la réalité de chaque équipe!

En fin de compte, ça sert à quoi le DevOps?

S’il y a une leçon à tirer de l’aventure de nos deux équipes, c’est qu’il n’y aura jamais de recette magique pour déterminer quand et comment le DevOps devrait être employé. C’est à l’équipage de connaître les besoins de son navire et d’utiliser tout instrument à sa disposition pour arriver à destination; que ce soit l’optimisation, la fiabilité ou la sécurité.


On en apprend plus chaque jour. Pierre-Antoine remarque que ses équipes de développeurs·euses ont déjà meilleure conscience de l’environnement dans lequel leurs applications évoluent. En conséquence, leurs estimations de performance requise sont mieux ciblées : on économise énormément de temps et on prévient une foule de problèmes en évitant de passer sans cesse de l’équipe de développement à celle des TI.

Pour Yohan, la présence de plus en plus de logiciels dans le Cloud offre une plus grande banque d’interfaces de programmation d'applications (API) à exploiter, permettant au logiciel d’une entreprise de souligner les forces d’un logiciel partenaire, et aussi de fournir les données nécessaires pour convaincre un client potentiel.

De votre côté, on vous souhaite bon voyage dans votre exploration de ce nouvel espace au croisement du développement et des opérations. Et, si vous vous en découvrez une passion, pourquoi ne pas vous joindre à nous. On cherche toujours de nouveaux membres d’équipage!