Dette technique : L'obsolescence technique

• Pour plus de détails sur la dette technique, vous pouvez lire les autres articles de cette série :
• La qualité du code
• Performance Back-End
• Performance Front-End
• Les bonnes pratiques

Ce sujet peut paraître évident et moins compliqué à mesurer. Il concerne la mise à jour de vos outils afin de ne pas prendre de retard par rapport à la dernière version, que ca soit la version de votre langage, de votre moteur de base de données, ou de votre outil (CMS, ecommerce, …). 

Sur ce point il est assez simple de voir combien de versions de retard on constate, mais il n’est pas toujours évident de savoir quand faire une mise à jour afin de ne pas trop les multiplier ni de prendre trop de retard. 

Mettre à jour vos outils

Les versions évoluent vite et leur support ne sont pas éternels. Il faut absolument éviter la situation où l’on se retrouve avec une version dépassée non mise à jour car, en plus de la dette technique accumulée, vous vous exposez à des risques de sécurité importants.

Nous conseillons à nos clients de ne pas installer immédiatement une version, pour de ne pas “essuyer les plâtres”, mais de ne pas prendre plus d’une ou 2 versions de retard. Très souvent une mise à jour d’une ou 2 versions n’est pas très complexe, là où la mise à jour de 5 ou 6 versions, voir de plusieurs versions majeures peut devenir beaucoup plus lourde et risquée.

Le plus gros du travail sur les mises à jour concernant le test pour valider la non régression. Il est aussi conseillé, si possible, de grouper par exemple une mise à jour d’outil et de version de langage, les 2 étant souvent liés. Cela peut vous permettre de ne tester qu’une seule fois.

L’exemple de Drupal

Pour prendre un exemple concret : voici l’exemple de la roadmap Drupal

Ceux qui connaissent bien Drupal auront tout de suite remarqué qu’il manque les versions après la version 8.4. Cependant, cet exemple est assez représentatif car la majorité des outils modernes sont sur des roadmaps assez similaires : une nouvelle version majeure tous les 18 à 24 mois et une version mineure tous les 3 à 6 mois (hors mises à jour de sécurité).

Ce qui laisse à supposer que si vous prenez 2 à 3 versions de retard, vous aurez rapidement accumulé 1 an de retard. Vous vous apercevrez aussi que le support d’une version majeure obsolète raccourci et correspond approximativement à la durée de la version suivante. Si on prend un exemple standard : Drupal 8 conservera des mises à jour de sécurité approximativement jusqu’à la sortie de drupal 10. 

Une autre information importante que la majorité des grands outils mettent en place : la dernière version mineure est en général une préparation de la version majeure suivante pour faciliter sa migration. Si je reprend l’exemple de Drupal, la version 8.9 prépare le terrain pour une migration vers la version 9. Il est donc très pertinent de prévoir une migration vers cette version. 

Nous ne conseillons en général pas à nos clients d’installer une version X.0. Le fait d’avoir une version 8.9 permet donc à la fois d’être prêt pour drupal 9 mais aussi de ne pas avoir trop de versions de retard, si on ne décide de migrer qu’à la version 9.1 ou 9.2.

Pour conclure

Ne négligez ni la veille nécessaire pour connaitre les nouvelles mises à jour ou les mises à jour de sécurité, ni les mises à jour qui doivent arriver régulièrement. Rien ne peut être pire pour votre projet que d’accumuler du retard sur la version de vos outils et de vous retrouver à ne plus pouvoir faire aucune mise à jour.

Les autres articles de cette série :

• Qualité du code
• Performance Back-End
  Performance Front-End
  Les bonnes pratiques