Introduction

Depuis plus de vingt ans maintenant, le monde du développement peut compter sur l’aide des frameworks. Ces fameuses bibliothèques de code, open source ou non, simplifient et accélèrent la réalisation de nos projets informatiques.

Cependant, depuis quelques années, leur utilisation a également été source de problèmes, comme le framework Struts, qui a présenté une faille de sécurité très grave permettant l’exécution d’un script côté serveur. Plus récemment, le framework Log4J2 a également posé problème pour des raisons similaires.

Dans cet article, nous allons examiner les frameworks les plus répandus sur une stack Java classique, en mettant en lumière leurs avantages ainsi que les contraintes importantes qu’ils imposent de manière coercitive.

La Stack Java (côté back)

Aujourd’hui, le langage Java reste le plus utilisé, suivi de près par le .NET. Ils sont talonnés par le JavaScript et le Python. Né dans les années 1990 pour remplacer le C/C++, les différentes politiques financières de Sun, puis d’Oracle, n’ont clairement pas aidé à leurs survie respectives. Heureusement, son utilisation dans les téléphones Android, ainsi que les frameworks qui sont venus combler et corriger ses lacunes, lui permettent d’exister et de continuer à évoluer jusqu’à nos jours.

La stack Java nécessite de prendre des décisions à chaque étape. En Java, vous êtes libre de choisir, contrairement au .NET où vous n’avez qu’à suivre la stack .NET déjà complète. Cette liberté impose de définir des frameworks externes gérés par des sociétés tierces ou des développeurs indépendants.

Un framework est un ensemble de code plus ou moins important qui répond à un ou plusieurs besoins. Par exemple :

Log4J2 : permet de gérer le log dans vos applications de manière extrêmement fine et paramétrable

• Lombock : permet de générer via des annotations dans le code des méthodes qu’il n’est plus nécessaire de coder
• Jackson : permet de prendre en charge toutes les problématiques de flux JSON en entrée et en sortie
• Spring : couvre un très large spectre de fonctionnalités allant du back au front en passant par le cloud et la sécurité

Il est absolument impossible de développer sans ces frameworks, ils sont indispensables. Ils apportent de vrais gains de productivité et rendent de réels services.

Mais où est le problème alors ? Il y en a plusieurs, certains sont simples à gérer, d’autres beaucoup plus complexe.

Problématique des interdépendances

Dans un projet classique, on va faire usage de plusieurs frameworks en même temps. Le problème peut survenir lorsque vous avez ce que l’on appelle des dépendances transitives entre eux.

Un exemple simplifié : dans votre projet, vous faites directement usage de log4j dans sa version 2.2.0, mais vous faites aussi usage d’un autre framework, disons le framework XXX, qui lui-même a besoin de log4j mais dans sa version 1.2. Si vous ne faites rien, vous allez avoir dans votre projet deux fois le framework log4j dans deux versions différentes. Le résultat sera aléatoire (dépendra de qui sera chargé en mémoire en premier) et, de fait, très problématique.

Que faire ? Vous ne pouvez pas garder plusieurs versions d’un même framework dans votre projet, c’est techniquement très risqué. Il va falloir choisir celle que vous voulez conserver.

Dans 99 % des cas, vos dépendances envers vos frameworks sont liées à votre outil de build. En Java, il en existe plusieurs (vous vous rappelez, il faut choisir). Heureusement, presque tous vous donnent les moyens de rectifier le problème. Maven (géré par la communauté Apache) et Gradle (géré par Google) sont les deux outils de build les plus répandus en Java. À titre d’exemple, pour forcer la version que vous voulez garder en Maven, il suffit de l’indiquer dans une section depencyManagement

Avec cette solution, vous avez la garantie que seule la version indiquée sera utilisée, mais vous n’avez pas la garantie que votre framework XXX, qui avait lui besoin de log4j 1.2, fonctionnera correctement. Dans mon exemple, j’ai opté pour la version la plus récente de log4j, mais j’aurais aussi pu choisir la 1.2, c’est-à-dire la plus ancienne. Ce faisant, notre framework XXX fonctionnerait sans problème, mais plus notre code dans notre projet.

Heureusement pour nous, les frameworks sérieux sont bien construits et prennent en compte presque tous les scénarios. Dans notre cas, log4j dans sa version 2.2.0 propose un complément rétro-compatible avec la version 1.2. Pour que notre projet fonctionne correctement, il nous suffira de l’ajouter à nos dépendances. Ainsi, nous aurons une bibliothèque supplémentaire pour garantir le bon fonctionnement de notre fameux framework XXX.

Problématique de versions

C’est un problème qui se rencontre parfois avec le précédent. L’ensemble des frameworks et de leurs versions sont référencés sur ce que l’on appel des repository.

Par exemple, les versions de Spring Core :

On peut y retrouver un grand nombre d’informations, telles que les problématiques de sécurité, les dépendances transversales, ainsi que les dates de releases.

Que se passe-t-il quand je veux changer une version d’un framework ?

Je vais volontairement partir sur un cas complexe : je veux passer de Spring Core 5.3.30 à Spring Core 6.0.12.

Si vous avez suivi le chapitre précédent, vous me direz : « c’est super simple, je change dans mon outil de build ma version et hop, le tour est joué ».

Dans les cas simples, vous auriez entièrement raison, mais malheureusement, dans notre cas, cela ne sera pas aussi trivial.

Avant tout changement de version, vous devez impérativement lire les changelogs associés au framework visé. Ces documents sont disponibles sur le site de l’éditeur du framework et contiennent l’ensemble des changements. Concentrez-vous sur les changements majeurs. Dans notre exemple, les changelogs vous indiqueront que pour faire usage du Spring Core dans sa version 6, vous devrez obligatoirement faire usage de Java dans sa version 17 minimum.

Cette contrainte, passer en Java 17, peut à elle seule casser la totalité de votre stack technique. En effet, qu’en est-il des autres frameworks ? Supportent-ils la version 17 de Java ? Et si votre projet est un projet web, qu’en est-il des serveurs d’applications ? Faudra-t-il aussi les faire passer en Java 17 ?

Je pense que vous l’aurez compris, dans mon exemple, on se retrouve avec un magnifique effet avalanche qui affectera tout votre SI.

Contrairement à notre problématique précédente, il n’y a pas ici de solution simple ou miraculeuse. Il va falloir sonner à tous les étages du SI : urbanistes, architectes, productions, DevOps, RSSI, … afin d’évaluer la pertinence ou non de réaliser cette migration qui s’est transformée en chantier de migration

Faut-il changer de version

Question très sage s’il en est. Nous avons pu constater qu’un petit changement peut entraîner de gros chantiers.

Différents cas de figure peuvent se présenter :

• Vous changez car il y a un gros problème de sécurité sur le framework : le changement est impératif, il faut le faire sauf contre ordre du RSSI qui en assumera les conséquences
• Vous changez car il y a un changement dans la stack technique : par exemple vous passez de Java 8 à Java 20. Dans ce cas de figure, vous n’êtes pas contraint d’aller vite, via de la conteneurisation vous pouvez laisser vivre vos différentes versions sans entrainer un effet avalanche.
• Vous changez car vous faites une refonte de l’application : c’est le plus simple, vous avez toute liberté dans vos choix

Hormis les problématiques techniques, n’oubliez pas de vous poser les deux questions qui fâchent :

• Quel est votre budget : un changement de version peut coûter un ou deux jours comme il peut aussi vous en prendre trois cents.
• Comment allez vous faire vos validations : avez-vous des outils automatisés pour vos tests, avez-vous des plans de tests à faire valider par votre MOA. Tout ceci n’est pas gratuit ni en temps ni en argent, pensez à planifier.

Maintenant, pour répondre à cette question : Faut-il changer de version de framework ? la réponse devrait toujours être oui, sauf si pour vous l’application est morte ou doit mourir. En effet, vous n’échapperez pas à la course en avant des stacks techniques, qui sont là pour garantir la sécurité et la performance de vos projets. Il est, de nos jours, impossible de rester sur une version d’un framework pendant plus d’un an.

Si je garde la stack Java comme exemple :

• Vous avez au minimum une version majeure du Spring par an
• Vous avez deux versions de Java par an, dont une majeure (les fameuses LTS) tous les 3/4 ans

Côté front, si vous faites de l’Angular : vous avez une version majeure par an.

Une version majeure signifie que le code de vos applications, parfois même leur organisation, changeront à cause du framework. Typiquement, votre code risque de ne plus compiler, ou de ne plus fonctionner voir de ne plus passer les analyses qualités.

Quand changer de version

Maintenant que vous avez compris que vous ne pourrez pas échapper aux changements de versions, il faut se poser la question du « quand changer de version ».

Disons-le tout de suite, il n’y a pas de bon moment ; le plus important, c’est de l’intégrer dans votre planification de projet avec un chiffrage acceptable.

Pour planifier une date cohérente, le plus simple est d’aller regarder sur les sites de chacun de vos frameworks majeurs. Ils ont tous des roadmaps qui sont globalement respectées. Prenez la date officielle et ajoutez-y un ou deux mois, histoire de :

• Ne pas essuyer les plâtres et différents bugs dans la nouvelle version du framework
• S’assurer une marge au cas où il y aurait du retard dans la roadmap du framework

Si votre projet dure 6 mois (on parle de délai ici, pas de charge), vous pouvez provisionner 5 à 10 jours/homme afin de réaliser vos changements de versions. C’est un chiffrage moyen qui va dépendre de la complexité et de la criticité de votre application.

Ce chiffre sera multiplié par trois si votre projet s’étale sur 1 an. Je vous encourage à provisionner 15 à 25 j/h pour garantir que vos changements de versions se feront sans écueil.

Selon la durée de votre projet, vous n’êtes pas obligé de faire toutes les migrations en même temps. Vous pouvez d’abord effectuer le back-end sur X j/h, puis le front-end sur Y j/h. Cela vous donnera plus de souplesse sur les applications complexes ou critiques.

Comment rester serein

Pour ceux qui ont connu l’informatique des années 1980, les changements de versions étaient réalisés de manière très lente et réfléchie.

De nos jours, ces changements sont quasi-quotidiens et ont nécessité la mise en place des processus DevOps.Pour attaquer sereinement vos changements de versions dans vos applications il est impératif d’avoir :

• Un cycle d’intégration continu opérationnel et précis
• Des tests unitaires, j’insiste ici sur le fait que ce sont des tests unitaires

S’il vous manque déjà un de ses deux éléments, ne cherchez pas à changer de versions de framework mais commencez plutôt à les mettre en place.

Il est aussi fortement conseillé d’avoir :

• Un cycle de déploiement continu
• Des tests d’intégrations

Dans un monde idéal, nous devrions tous avoir en plus :

• Des analyses qualité automatisées
• Des analyses sécurités automatisées
• Des tests de charges cohérents
• Des recettes utilisateurs outillées

Conclusion

Dans un monde de développement informatique en constante évolution, les frameworks jouent un rôle crucial en accélérant les projets, mais les changements de versions posent des défis majeurs.

Notre accompagnement chez Lena IT se révèle être une ressource précieuse dans ce contexte en constante mutation. Notre expertise en matière de développement, de gestion des versions et de planification stratégique peut vous aider à naviguer en toute confiance à travers ces changements. De l’intégration continue aux tests automatisés, en passant par les analyses de qualité et de sécurité, nous vous offrons un soutien complet pour garantir des transitions harmonieuses vers de nouvelles versions de frameworks.

La gestion efficace des changements de frameworks est devenue essentielle, et avec un soutien adéquat, les équipes peuvent naviguer avec confiance dans ce paysage technologique en constante mutation.