4 min de lecture
La connaissance est précieuse, mais son véritable pouvoir réside dans sa mise en pratique. Chez Freyr Digital, nous étions familiers avec le DevOps, ses pratiques associées et la manière dont il pouvait transformer notre organisation en un pôle de développement de produits hautement performant, capable de fournir des produits et des solutions de qualité à nos clients des sciences de la vie. Au début de notre parcours, nos efforts ont jeté de solides bases, mais pour devenir véritablement un pôle de développement, nous savions que nous devions adopter une approche plus stratégique et adaptative.
Le principal défi lorsqu'il s'agit de passer de la théorie à la pratique réside dans le fait de savoir quand agir. Les actions ayant un impact sur un grand nombre de personnes au sein d'une organisation, agir au bon moment et de la bonne manière dépend de notre position en tant qu'entreprise, de nos processus et pratiques actuels, ainsi que des compétences et des capacités de nos équipes.
Cela a marqué un tournant dans notre transformation. En tant qu'éditeur de logiciels spécialisé dans les solutions sur mesure, nous disposions d'une équipe dédiée qui n'a pas ménagé ses efforts pour obtenir des résultats. Nous avons toutefois identifié une opportunité d'améliorer la qualité, d'accroître la productivité et d'accélérer la transformation des exigences commerciales en livrables. Plutôt que de nous concentrer sur les correctifs de dernière minute, nous avons cherché à passer d'une résolution réactive des problèmes à une innovation proactive, afin de créer des solutions évolutives et à fort impact.
Nous avions une vision claire de nos ambitions : la manière dont nous souhaitions travailler, développer, tester, déployer et publier des logiciels. Nous savions toutefois que pour atteindre ces objectifs, il fallait une stratégie réfléchie, un apprentissage continu et un engagement constant envers l'amélioration.
Pour résumer la situation actuelle : au cours de la dernière année, nous avons réalisé plus de 100 versions avec un taux d'échec de déploiement proche de zéro, et nous avons atteint une automatisation quasi totale du déploiement des modifications. En outre, nous avons constaté une progression significative de notre chiffre d'affaires, des équipes plus restreintes et plus agiles, ainsi qu'une évolution globale vers notre vision de devenir un leader des produits, solutions et services logiciels. Bien qu'il reste toujours des objectifs à atteindre, nous avons la certitude d'avoir jeté des bases solides et d'être prêts à accélérer notre développement.
Alors que nous allons de l'avant, nous prenons le temps de réfléchir à notre transformation : ce qui a fonctionné, ce qui a échoué et les leçons que nous en avons tirées. En partageant notre parcours, nous espérons aider d'autres entreprises confrontées à des transformations similaires.
Cette série d'articles est principalement empirique. Elle présente nos actions tout en les rattachant aux meilleures pratiques et recommandations issues de diverses ressources DevOps et Agile.
Agir de la bonne manière au bon moment
L'un des aspects clés de notre transformation a consisté à identifier les bonnes actions au bon moment. Face à la multitude d'initiatives possibles, nous avions besoin d'une approche structurée pour garantir des progrès significatifs.
Avec du recul, nous pouvons regrouper ces actions en trois catégories : les outils et les processus, l'architecture logicielle et les personnes. Ces domaines sont étroitement liés, les changements apportés à l'un ayant des répercussions sur les autres. Il a toutefois été possible d'apporter des modifications progressives dans chaque catégorie et de mesurer les progrès accomplis par rapport à nos objectifs globaux.
Les initiatives de ces catégories étaient souvent interdépendantes. Les changements effectués dans un domaine ouvraient de nouvelles perspectives d'amélioration dans un autre.
Les premiers pas
Pour établir des bases solides, nous nous sommes concentrés sur trois initiatives principales :
- L'intégration de nos bases de code source avec SonarQube pour obtenir des mesures de qualité du code.
- L'adoption par toutes les équipes d'un outil commun pour la gestion des exigences, du code source et des plans de test — en l'occurrence, Azure DevOps.
- La structuration des équipes avec des responsabilités claires pour renforcer l'appropriation et l'imputabilité.
Ces trois initiatives nous ont offert une visibilité sur :
- Le travail en cours (exigences et tâches).
- La qualité du code (mesures SonarQube).
- Les personnes impliquées (responsabilités de l'équipe).
Parmi ces défis, la définition de responsabilités claires au sein des équipes a été le plus complexe. Au départ, la structure des équipes était fluide et les collaborateurs changeaient de projet selon les besoins. Le passage à des équipes dédiées dotées de domaines fonctionnels distincts était une étape nécessaire, bien que compliquée par notre architecture de produits existante, qui n'avait pas été entièrement conçue pour garantir une appropriation claire.
Le rôle de l'architecture logicielle
Nous avons rapidement compris que l'architecture des produits constituait l'un des aspects nécessitant le plus de changements. Une architecture modulaire était indispensable pour permettre à des équipes autonomes de s'approprier leur travail. Sans cela, nos efforts pour responsabiliser les équipes auraient eu un impact limité.
La refonte de notre portefeuille a été un processus complexe. Elle a impliqué une transition totale vers le cloud et le début du développement d'applications natives cloud basées sur une architecture de microservices. Ce sujet sera abordé dans un prochain article. Retenez toutefois que les changements sont progressifs et que certaines étapes doivent précéder les autres pour porter leurs fruits et avancer efficacement.
Indicateurs et amélioration continue
Après avoir entamé les travaux de refonte architecturale (un processus permanent), nous avons concentré nos efforts sur le suivi des indicateurs et la fixation d'objectifs :
- Indicateurs de qualité du code dans SonarQube.
- Indicateurs d'intégration du code dans Azure DevOps.
- Indicateurs de productivité des fonctionnalités pour chaque équipe.
- Adoption de services natifs cloud.
Ces objectifs n'étaient pas des contraintes strictes, mais des repères pour aider les équipes à aligner leurs efforts.
Valoriser les équipes
Une fois les indicateurs en place, il est apparu évident que les équipes avaient besoin de soutien pour atteindre ces objectifs. Par exemple, s'il était facile de fixer des objectifs en matière de couverture des tests unitaires et d'automatisation des tests d'API, il était difficile de les atteindre, en particulier pour le code existant qui n'avait pas été conçu pour être testé.
Pour y remédier, nous avons :
- Fixé des objectifs moins élevés pour le code existant.
- Organisé des ateliers et des formations pratiques sur la rédaction de tests unitaires de qualité et la conception de code testable.
- Fourni des conseils pour créer des stubs destinés aux tests d'API.
- Réalisé des revues de tests unitaires avec des architectes séniors.
Le triptyque : outils, architecture et compétences
La gestion du code et des dépôts illustre parfaitement l'interaction entre ces différents éléments. L'intégration de SonarQube, qui représente une amélioration des outils, a mis en évidence une faible couverture des tests unitaire, révélant ainsi des problèmes d'architecture limitant la testabilité. Grâce à l'amélioration de l'architecture et des compétences des équipes, nous avons obtenu des tests unitaires de meilleure qualité. Cependant, ceux-ci n'étaient pas exécutés régulièrement en raison de mauvaises pratiques de gestion des branches. Nous avons résolu ce problème en standardisant nos stratégies de branches et en garantissant l'intégration régulière du code dans la branche principale, ce qui a permis aux pipelines CI d'exécuter l'ensemble des tests.
La bonne séquence de changement
Une méthode de transformation consiste à appliquer les meilleures pratiques sans distinction. Bien que cela puisse présenter des avantages, les résultats ne compensent souvent pas les efforts fournis, ce qui engendre de la frustration.
Nous avons adopté une approche différente, basée sur le principe de flux : analyser le processus End-to-End, identifier les goulots d'étranglement et les résoudre progressivement.
Chaque amélioration a révélé de nouveaux goulots d'étranglement, nécessitant des actions supplémentaires. Il ne s'agissait pas de faire face aux problèmes au compte-gouttes, mais d'adopter une démarche réfléchie pour accomplir la bonne action au bon moment.
Par exemple, imposer une obligation de couverture des tests unitaires sans améliorer la conception du code aurait provoqué de la frustration et une « illusion de couverture » (des tests superficiels rédigés uniquement pour atteindre les objectifs chiffrés). En traitant d'abord l'architecture et les compétences, nous avons garanti des progrès réels.
Perspectives d'avenir
Une véritable transformation ne repose pas sur un bouleversement soudain, mais sur des décisions judicieuses et opportunes qui favorisent un progrès continu. Nous sommes ravis de partager notre parcours et notre expérience pour aider d'autres structures à réussir leur transition vers un changement évolutif et à fort impact.
Dans les prochains articles de cette série, intitulée DevOps for the Win, nous décortiquerons chaque phase de notre transformation au sein du triangle DevOps (outils, architecture et personnes) pour montrer comment elle nous a permis d'obtenir des résultats durables.
