Operation Health : traiter la dette technique pour la qualité

Transformer un point de douleur des développeurs en démarche qualité à l'échelle.

L'an dernier, chez Medexprim , nos développeurs exprimaient depuis un moment le besoin de traiter des problèmes techniques pressants, des préoccupations systématiquement reléguées derrière nos priorités quotidiennes. Samuel Boucher , inspiré par l'initiative d'Ubisoft, a proposé notre propre « Operation Health ». En tant que CPTO, j'ai saisi cette occasion, en choisissant une période morcelée de décembre 2023 pour concrétiser cette idée.

Cette pause de deux semaines dans le développement habituel nous a permis de nous concentrer sur notre dette technique, en traitant les problèmes accumulés et en améliorant notre base de code et notre infrastructure.

S'inspirer de l'Operation Health d'Ubisoft

Notre Operation Health s'est directement inspirée de l'initiative éponyme d'Ubisoft. En 2017, Ubisoft a franchi un cap audacieux avec son jeu Rainbow Six Siege, en suspendant la sortie de nouveaux contenus pendant une saison entière pour se concentrer sur l'amélioration de l'infrastructure technique du jeu.

https://www.youtube.com/watch?v=-vU1HsleM4M

Les points clés de l'Operation Health d'Ubisoft :

1. Du temps dédié : trois mois réservés aux améliorations techniques.
2. Focus sur les problèmes de fond : traiter les problèmes fondamentaux qui affectent l'expérience des joueurs.
3. Vision de long terme : privilégier la longévité et la stabilité du jeu plutôt que la livraison de contenu à court terme.
4. Transparence : communication ouverte avec la communauté sur le processus.

Le courage d'Ubisoft, faire passer la santé technique avant les gains à court terme, nous a inspirés.

Notre règle d'or pour Operation Health : la liberté d'agir

Le principe de base était simple mais essentiel : les ingénieurs étaient libres de choisir les problèmes à résoudre. Cette liberté s'étendait à tous les aspects :

• Le choix des tâches à mener : améliorer un produit, corriger un bug, travailler sur le DevOps, ou explorer un nouveau sujet technique jamais traité jusque-là
• La définition de leur propre méthode de travail
• Le choix des technologies à utiliser ou à améliorer

Cette autonomie a permis à notre équipe de traiter un large éventail de sujets, des améliorations produit immédiates aux explorations techniques de long terme.

Samuel, à l'origine du projet, a commenté : « Cette liberté a permis à chacun de s'attaquer aux problèmes qui le frustraient depuis longtemps, ou d'explorer des domaines techniques qu'il jugeait cruciaux pour nos développements futurs. »

La structure d'Operation Health

En tant que CPTO, j'ai choisi de mener cette opération pendant une période très morcelée, le mois de décembre. Ce calendrier n'était pas idéal, mais c'était un choix pragmatique. Cette période ne nous aurait de toute façon pas permis d'avancer en profondeur sur notre roadmap habituelle, alors nous avons décidé qu'il valait mieux la consacrer à Operation Health plutôt que de ne pas traiter du tout notre dette technique.

Préparation (3 semaines en amont)

1. Un brainstorming autour des questions suivantes :

• qu'est-ce qui peut tout casser ?
• qu'est-ce qui peut nous sauver ?
• qu'est-ce qui nous manque ?
• ici se cachent les dragons :)

2. Sélectionner les actions à mener

Exécution (2 semaines, environ 5 jours ouvrés effectifs)

• Liberté totale d'organisation pour les 7 ingénieurs impliqués
• Travail sur les actions sélectionnées

Conclusion (réunion de 2 heures)

• Identification des actions inachevées
• Évaluation des résultats et communication
• Analyse des enseignements

Cette structure nous a permis de tirer le meilleur d'une période habituellement peu productive, en la transformant en une occasion d'amélioration ciblée, même si les conditions n'étaient pas optimales.

Organisation

Tout en mettant l'accent sur l'autonomie, nous avons aussi mis en place un cadre pour garantir la productivité et la responsabilisation :

1. Engagement sur les sujets choisis : une fois qu'un ingénieur avait sélectionné un sujet, il était attendu qu'il le mène jusqu'au bout.
2. Documentation et livrables : chaque sujet traité devait être soigneusement documenté, avec l'objectif de produire au moins un livrable tangible par sujet.
3. Points quotidiens : nous tenions de brefs points quotidiens pour que chacun partage son avancement, ses difficultés et ses enseignements.
4. Un board dédié : Samuel a mis en place un tableau spécifique, composé de deux parties :

• Suivi des tâches : une section listant les tâches de chaque ingénieur et leur statut du moment.
• Demandes de collaboration : un espace où chacun pouvait signaler s'il avait besoin d'aide, que ce soit pour une simple discussion autour d'un café, un coup de main plus conséquent, ou parce qu'il était complètement bloqué sur un problème.

Cette approche équilibrée laissait place à la liberté individuelle tout en maintenant un cap collectif sur nos objectifs.

Projets clés et résultats

Nos ingénieurs se sont concentrés sur des domaines précis, avec des résultats intéressants :

• Yonatan Ramirez De Groen en plus de nettoyer tout le dépôt d'images, a joué un rôle clé pour soutenir l'équipe, en débloquant ses collègues à des moments cruciaux (voir la citation ci-dessous !)
• Mathieu G. a optimisé notre gestion des paquets Python
• Cécile Heyvaert a mené un audit approfondi de nos pipelines CI/CD
• Antoine Vigneron a renforcé nos tests unitaires

Ces projets ont non seulement amélioré notre infrastructure technique, mais aussi apporté des enseignements précieux sur nos processus de développement.

Éloïse a témoigné : « J'ai enfin pu résoudre ce bug récurrent qui nous embêtait depuis des mois. »

Enseignements et difficultés

1. Traiter les problèmes négligés est satisfaisant : les ingénieurs ont enfin travaillé sur des tâches toujours reléguées. C'étaient souvent de petits problèmes agaçants qui n'avaient jamais semblé assez importants pour être priorisés. Résoudre ces irritants de longue date a été profondément satisfaisant pour l'équipe. Cela a libéré l'esprit et remonté le moral.
2. La collaboration inter-équipes apporte de nouveaux regards : l'opération a réuni différentes équipes autour d'un même travail. Cela a généré plus d'échanges inter-équipes que d'habitude. Les gens ont partagé leurs connaissances et résolu des problèmes ensemble, de façons nouvelles. Beaucoup ont exprimé le souhait de poursuivre cette approche collaborative à l'avenir.
3. Investir du temps maintenant en fait gagner plus tard : beaucoup des problèmes traités faisaient perdre du temps aux développeurs en permanence. Par exemple, nettoyer notre dépôt d'images Docker rendra les déploiements plus rapides et plus fiables. Optimiser la gestion des paquets et augmenter la couverture de tests évitera de futurs bugs et fera gagner du temps de débogage. Ces améliorations paieront sur le long terme.
4. Les outils collaboratifs renforcent le travail d'équipe : le board Miro a été incroyablement utile. Il permettait à chacun de demander de l'aide sans interrompre les autres. On pouvait signaler qu'on avait besoin d'une pause café rapide ou qu'on était complètement coincé. Cela a rendu la collaboration plus simple et plus fréquente. Les membres de l'équipe consultaient le board et aidaient les autres avant de démarrer de nouvelles tâches.

Comme l'a noté Yonatan, l'un de nos ingénieurs : « Le board Miro a tout changé. Je voyais facilement qui avait besoin d'aide et je pouvais proposer mon expertise sans avoir l'impression de m'imposer. Cela a vraiment fait tomber les barrières entre les équipes. »

Impact sur notre culture d'entreprise

Operation Health a apporté quelques bénéfices à court terme à notre équipe :

• Elle a rappelé, à point nommé, l'importance de la qualité du code.
• Elle a temporairement remonté le moral et la motivation de l'équipe.
• Elle nous a permis de traiter certains problèmes de longue date dans notre base de code.

Si l'expérience a été positive sur le moment, son impact à long terme a été plus limité. L'enthousiasme à maintenir la qualité du code s'est estompé peu à peu à mesure que nous reprenions notre cycle de développement habituel. Cette initiative a mis en lumière la difficulté d'inscrire ces améliorations dans la durée dans un environnement MedTech à rythme soutenu, en nous montrant que des périodes dédiées au traitement de la dette technique, bien qu'utiles, ne sont pas une solution complète pour la santé du code sur le long terme.

Conclusion

Même si notre Operation Health a été indéniablement bénéfique, je dois admettre que je ne suis pas entièrement convaincue que ce soit l'approche idéale. Personnellement, je crois fermement que la dette technique devrait se traiter au quotidien, intégrée à notre flux de travail habituel. Idéalement, nous ne devrions pas avoir besoin d'événements spéciaux pour nous attaquer à ces sujets.

Mais la réalité du développement logiciel, surtout dans un environnement de startup à rythme soutenu, nous oblige souvent à faire des arbitrages. Nous cherchons en permanence l'équilibre entre le besoin d'avancer vite et le maintien d'un haut niveau de qualité de code. Tout est affaire de bon compromis entre vitesse de développement et niveau de qualité approprié.

Cette opération a mis en lumière le défi permanent auquel nous faisons face : comment traiter la dette technique de façon régulière tout en répondant à nos besoins de développement urgents ? C'est une question avec laquelle nous continuerons de composer à mesure que nous grandissons et évoluons.

#OperationHealth #StartupLife #MedTech #CodeQuality #TechnicalDebt

À lire ensuite

Build in Public

J'ai voulu construire mon app sans savoir coder

IA & Santé

L'IA en santé : chronique d'un été