Nous avons choisi une technologie ? À nous d’assumer les maintenances, maintenant !

Développeur, développeuse.
Tous les jours, nous effectuons des choix, prenons des décisions.
Qui ont un impact sur nos projets et nos équipes.

Quel langage / framework / bibliothèque pour ce projet ? MySQL, DynamoDB ou MongoDB ? Monolithe, monolithe distribué, microservices, ou monolithe modulaire ? Kubernetes ou Lambda ?

Après ces choix et décisions, dans la vie de nos projets, régulièrement, des mises à jour arrivent…

Des mises à jour ?

À quoi je pense, quand je dis mises à jour ? Et bien :

• nouvelle version d’un outil open-source, nouvelle version d’un framework, nouvelle version du langage de programmation avec lequel nous travaillons ;
• plus difficile à gérer peut-être, fin de support de versions désormais fort anciennes ;
• et, souvent urgent¹, mises à jour de sécurité.

Hélas, face à ces mises à jour, les réactions vont souvent de « il faut demander au PO de libérer du temps (dans le prochain sprint) » à « on n’a pas le temps », en passant par « peut-être que ça rentrera dans la roadmap de l’année prochaine ».

Mais… Pourquoi ?

Nous avons choisi un outil, assumons !

C’est au moment du choix, au moment de la décision, souvent au lancement du projet ou au début du développement d’une fonctionnalité, que nous devrions inclure du temps de maintenance.

Arrêtons de nous voiler la face : nous savons que nous devrons gérer de la maintenance !

Nous savions, quand nous avons commencé à développer en PHP 8.1, que son support actif se terminerait le 25 novembre 2023 (et un an plus tard pour le support de sécurité). Nous savions, quand nous avons choisi MySQL 5.7 (sorti en 2015), que cette version ne serait pas supportée pour toujours.

Donc, prévoyons cette maintenance. Quand nous choisissons un outil, prévoyons² que nous allons devoir suivre sa vie, et y passer du temps pour ça — et annonçons-le, sans le cacher.

Quelques exemples ?

Allez, tous inspirés de cas réels — et avec plus de 15 ans d’XP, j’en ai vu pas mal ^^

Nous attaquons un projet de 500 jours de développement ?

Et bien, nous savons que nous allons devoir passer environ 50 jours³ de maintenance dessus tous les ans. Dès maintenant, nous pouvons l’annoncer : « bonjour, si nous lançons ce projet, il nous coutera 500 jours de mise en place, puis 50 jours tous les ans ».

Alors, pourquoi est-ce que nous ne prononçons jamais la seconde moitié de la phrase ?

Nous choisissons d’utiliser PHP pour votre prochain projet.

Nous savons que ce choix nous fait gagner X jours sur la phase de développement, parce que l’équipe connait bien le langage et son écosystème.

Par contre, nous savons aussi que cela ajoute X% de consommation CPU (et donc de cout machine), par rapport à tel autre langage (mettons Go ou Rust), pour toute la vie du projet, pendant des années.

Et, puisque le cycle de versions de PHP est public, nous savons aussi que, tous les mois, une nouvelle version patch est publiée et que certaines incluent des correctifs de sécurité — qu’il faut donc prévoir une montée de version tous les trois mois environs. Et nous savons aussi que tous les ans, nous devrons effectuer une montée de version mineure. Et que tous les 3 à 5 ans, nous devrons effectuer une montée de version majeure.

Nous choisissons de déployer Wordpress pour un site corporate⁴, au lieu de mettre en place un CMS statique⁵.

Nous savons que cela va simplifier le travail de nos collègues et que, sans ça, le site corporate ne sera jamais mis à jour — sauf si ils et elles se battent toutes les deux semaines avec les POs pour faire entrer des US de contribution dans nos sprints.

Mais nous savons aussi que nous allons devoir passer X jours par an en maintenance et en montées de version.

Nous avons décidé d’utiliser MySQL pour un projet. Nous avons aussi décidé de ne pas l’héberger et d’exploiter une offre managée comme Amazon RDS.

Nous allons ainsi économiser du temps sur les maintenances, nous bénéficierons d’une offre managée (pour les backups, le failover en cas de panne), de plus d’élasticité et plus de souplesse.

Mais nous aurons aussi moins de maitrises sur certains points. Par exemple, AWS va nous imposer des dates de fin de support pour MySQL 5.7 et forcer les mises à jour vers MySQL 8.0.

Dans chacun de ces cas, c’est un choix, un compromis. Et aucune des décisions (lancer un projet, utiliser PHP, déployer Wordpress, utiliser MySQL managé sur RDS) n’est mauvaise.

Soyons juste conscients qu’en face de chaque décision, il y a des conséquences.

Y penser, puis communiquer

Nous devons donc communiquer, de manière chiffrée et concrète, quand nous effectuons un choix, sur les conséquences de celui-ci.

Nous devons donc nous poser des questions, nous devons penser au futur et pas uniquement à l’instant présent, quand nous allons effectuer ces choix. Développeurs, encore plus pour celles et ceux qui se disent senior, nous ne sommes pas là pour coder un truc, mais pour apporter des réponses à des problématiques !

Et nous devons tenir compte de tout ça, du cout de maintenance, quand nous faisons nos choix… Et pas uniquement nous dire « on a toujours utilisé MySQL donc continuons ».

La maintenance, ça fait partie de notre boulot !

Enfin, si nous avons choisi PHP, si nous avons choisi RDS MySQL, c’est à nous qu’il revient de prévoir du temps, en avance, pour suivre les montées de versions et appliquer les correctifs de sécurité !

Nous ne devrions pas avoir à quémander du temps, comme si nous étions surpris, à chaque fois qu’une montée de version ou une maintenance est nécessaire. Ce temps devrait déjà être alloué, puisque nous aurions dû déjà l’avoir annoncé, dès le départ.

Illustration par Mathieu Stern sur Unsplash