{"id":1068,"date":"2023-10-11T14:15:00","date_gmt":"2023-10-11T12:15:00","guid":{"rendered":"https:\/\/www.lena-it.fr\/?p=1068"},"modified":"2023-11-22T09:52:19","modified_gmt":"2023-11-22T08:52:19","slug":"la-course-en-avant-des-versions-de-framework","status":"publish","type":"post","link":"https:\/\/www.lena-it.fr\/index.php\/2023\/10\/11\/la-course-en-avant-des-versions-de-framework\/","title":{"rendered":"La course en avant des versions de framework"},"content":{"rendered":"<p>[et_pb_section fb_built=\u00a0\u00bb1&Prime; _builder_version=\u00a0\u00bb4.21.0&Prime; _module_preset=\u00a0\u00bbdefault\u00a0\u00bb da_disable_devices=\u00a0\u00bboff|off|off\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb theme_builder_area=\u00a0\u00bbpost_content\u00a0\u00bb da_is_popup=\u00a0\u00bboff\u00a0\u00bb da_exit_intent=\u00a0\u00bboff\u00a0\u00bb da_has_close=\u00a0\u00bbon\u00a0\u00bb da_alt_close=\u00a0\u00bboff\u00a0\u00bb da_dark_close=\u00a0\u00bboff\u00a0\u00bb da_not_modal=\u00a0\u00bbon\u00a0\u00bb da_is_singular=\u00a0\u00bboff\u00a0\u00bb da_with_loader=\u00a0\u00bboff\u00a0\u00bb da_has_shadow=\u00a0\u00bbon\u00a0\u00bb][et_pb_row _builder_version=\u00a0\u00bb4.20.2&Prime; _module_preset=\u00a0\u00bbdefault\u00a0\u00bb width=\u00a0\u00bb100%\u00a0\u00bb max_width=\u00a0\u00bb100%\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb theme_builder_area=\u00a0\u00bbpost_content\u00a0\u00bb][et_pb_column type=\u00a0\u00bb4_4&Prime; _builder_version=\u00a0\u00bb4.20.2&Prime; _module_preset=\u00a0\u00bbdefault\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb theme_builder_area=\u00a0\u00bbpost_content\u00a0\u00bb][et_pb_image src=\u00a0\u00bbhttps:\/\/www.lena-it.fr\/wp-content\/uploads\/2023\/09\/La-course-en-avant-des-versions-de-framework.png\u00a0\u00bb alt=\u00a0\u00bbLa course en avant des versions de framework\u00a0\u00bb title_text=\u00a0\u00bbLa course en avant des versions de framework\u00a0\u00bb _builder_version=\u00a0\u00bb4.22.2&Prime; _module_preset=\u00a0\u00bbdefault\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb theme_builder_area=\u00a0\u00bbpost_content\u00a0\u00bb][\/et_pb_image][et_pb_text ul_item_indent=\u00a0\u00bb30px\u00a0\u00bb ol_position=\u00a0\u00bboutside\u00a0\u00bb ol_item_indent=\u00a0\u00bb30px\u00a0\u00bb _builder_version=\u00a0\u00bb4.22.2&Prime; _module_preset=\u00a0\u00bbdefault\u00a0\u00bb text_font_size=\u00a0\u00bb16px\u00a0\u00bb header_2_text_color=\u00a0\u00bb#386759&Prime; header_2_font_size=\u00a0\u00bb22px\u00a0\u00bb header_2_line_height=\u00a0\u00bb1.6em\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb theme_builder_area=\u00a0\u00bbpost_content\u00a0\u00bb]<\/p>\n<h2>Introduction<\/h2>\n<p>Depuis plus de vingt ans maintenant, le monde du d\u00e9veloppement peut compter sur l&rsquo;aide des frameworks. Ces fameuses biblioth\u00e8ques de code, open source ou non, simplifient et acc\u00e9l\u00e8rent la r\u00e9alisation de nos projets informatiques.<\/p>\n<p>Cependant, depuis quelques ann\u00e9es, leur utilisation a \u00e9galement \u00e9t\u00e9 source de probl\u00e8mes, comme le framework Struts, qui a pr\u00e9sent\u00e9 une faille de s\u00e9curit\u00e9 tr\u00e8s grave permettant l&rsquo;ex\u00e9cution d&rsquo;un script c\u00f4t\u00e9 serveur. Plus r\u00e9cemment, le framework Log4J2 a \u00e9galement pos\u00e9 probl\u00e8me pour des raisons similaires.<\/p>\n<p>Dans cet article, nous allons examiner les frameworks les plus r\u00e9pandus sur une stack Java classique, en mettant en lumi\u00e8re leurs avantages ainsi que les contraintes importantes qu&rsquo;ils imposent de mani\u00e8re coercitive.<\/p>\n<p>&nbsp;<\/p>\n<h2>La Stack Java (c\u00f4t\u00e9 back)<\/h2>\n<p>Aujourd&rsquo;hui, le langage Java reste le plus utilis\u00e9, suivi de pr\u00e8s par le .NET. Ils sont talonn\u00e9s par le JavaScript et le Python. N\u00e9 dans les ann\u00e9es 1990 pour remplacer le C\/C++, les diff\u00e9rentes politiques financi\u00e8res de Sun, puis d&rsquo;Oracle, n&rsquo;ont clairement pas aid\u00e9 \u00e0 leurs survie respectives. Heureusement, son utilisation dans les t\u00e9l\u00e9phones Android, ainsi que les frameworks qui sont venus combler et corriger ses lacunes, lui permettent d&rsquo;exister et de continuer \u00e0 \u00e9voluer jusqu&rsquo;\u00e0 nos jours.<\/p>\n<p>La stack Java n\u00e9cessite de prendre des d\u00e9cisions \u00e0 chaque \u00e9tape. En Java, vous \u00eates libre de choisir, contrairement au .NET o\u00f9 vous n&rsquo;avez qu&rsquo;\u00e0 suivre la stack .NET d\u00e9j\u00e0 compl\u00e8te. Cette libert\u00e9 impose de d\u00e9finir des frameworks externes g\u00e9r\u00e9s par des soci\u00e9t\u00e9s tierces ou des d\u00e9veloppeurs ind\u00e9pendants.<\/p>\n<p>Un framework est un ensemble de code plus ou moins important qui r\u00e9pond \u00e0 un ou plusieurs besoins. Par exemple\u00a0:<\/p>\n<p>Log4J2 : permet de g\u00e9rer le log dans vos applications de mani\u00e8re extr\u00eamement fine et param\u00e9trable<\/p>\n<ul>\n<li>Lombock : permet de g\u00e9n\u00e9rer via des annotations dans le code des m\u00e9thodes qu&rsquo;il n&rsquo;est plus n\u00e9cessaire de coder<\/li>\n<li>Jackson : permet de prendre en charge toutes les probl\u00e9matiques de flux JSON en entr\u00e9e et en sortie<\/li>\n<li>Spring : couvre un tr\u00e8s large spectre de fonctionnalit\u00e9s allant du back au front en passant par le cloud et la s\u00e9curit\u00e9<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>Il est absolument impossible de d\u00e9velopper sans ces frameworks, ils sont indispensables. Ils apportent de vrais gains de productivit\u00e9 et rendent de r\u00e9els services.<\/p>\n<p>Mais o\u00f9 est le probl\u00e8me alors ? Il y en a plusieurs, certains sont simples \u00e0 g\u00e9rer, d&rsquo;autres beaucoup plus complexe.<\/p>\n<h2>Probl\u00e9matique des interd\u00e9pendances<\/h2>\n<p>Dans un projet classique, on va faire usage de plusieurs frameworks en m\u00eame temps. Le probl\u00e8me peut survenir lorsque vous avez ce que l&rsquo;on appelle des d\u00e9pendances transitives entre eux.<\/p>\n<p>Un exemple simplifi\u00e9 : dans votre projet, vous faites directement usage de log4j dans sa version 2.2.0, mais vous faites aussi usage d&rsquo;un autre framework, disons le framework XXX, qui lui-m\u00eame 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\u00e9rentes. Le r\u00e9sultat sera al\u00e9atoire (d\u00e9pendra de qui sera charg\u00e9 en m\u00e9moire en premier) et, de fait, tr\u00e8s probl\u00e9matique.<\/p>\n<p>Que faire ? Vous ne pouvez pas garder plusieurs versions d&rsquo;un m\u00eame framework dans votre projet, c&rsquo;est techniquement tr\u00e8s risqu\u00e9. Il va falloir choisir celle que vous voulez conserver.<\/p>\n<p>Dans 99 % des cas, vos d\u00e9pendances envers vos frameworks sont li\u00e9es \u00e0 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\u00e8me. Maven (g\u00e9r\u00e9 par la communaut\u00e9 Apache) et Gradle (g\u00e9r\u00e9 par Google) sont les deux outils de build les plus r\u00e9pandus en Java. \u00c0 titre d&rsquo;exemple, pour forcer la version que vous voulez garder en Maven, il suffit de l&rsquo;indiquer dans une section <em>depencyManagement<\/em><\/p>\n<ul><\/ul>\n<p>[\/et_pb_text][et_pb_image src=\u00a0\u00bbhttps:\/\/www.lena-it.fr\/wp-content\/uploads\/2023\/09\/depencyManagement.png\u00a0\u00bb alt=\u00a0\u00bbdepencyManagement\u00a0\u00bb title_text=\u00a0\u00bbdepencyManagement\u00a0\u00bb align=\u00a0\u00bbcenter\u00a0\u00bb _builder_version=\u00a0\u00bb4.22.2&Prime; _module_preset=\u00a0\u00bbdefault\u00a0\u00bb module_alignment=\u00a0\u00bbcenter\u00a0\u00bb custom_margin=\u00a0\u00bb0px||||false|false\u00a0\u00bb custom_padding=\u00a0\u00bb0px||||false|false\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb theme_builder_area=\u00a0\u00bbpost_content\u00a0\u00bb][\/et_pb_image][et_pb_text ul_item_indent=\u00a0\u00bb30px\u00a0\u00bb ol_position=\u00a0\u00bboutside\u00a0\u00bb ol_item_indent=\u00a0\u00bb30px\u00a0\u00bb _builder_version=\u00a0\u00bb4.22.2&Prime; _module_preset=\u00a0\u00bbdefault\u00a0\u00bb text_font_size=\u00a0\u00bb16px\u00a0\u00bb header_2_text_color=\u00a0\u00bb#386759&Prime; header_2_font_size=\u00a0\u00bb22px\u00a0\u00bb header_2_line_height=\u00a0\u00bb1.6em\u00a0\u00bb custom_margin=\u00a0\u00bb0px||0px||false|false\u00a0\u00bb custom_padding=\u00a0\u00bb0px||0px||false|false\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb theme_builder_area=\u00a0\u00bbpost_content\u00a0\u00bb]<\/p>\n<p>Avec cette solution, vous avez la garantie que seule la version indiqu\u00e9e sera utilis\u00e9e, mais vous n&rsquo;avez pas la garantie que votre framework XXX, qui avait lui besoin de log4j 1.2, fonctionnera correctement. Dans mon exemple, j&rsquo;ai opt\u00e9 pour la version la plus r\u00e9cente de log4j, mais j&rsquo;aurais aussi pu choisir la 1.2, c&rsquo;est-\u00e0-dire la plus ancienne. Ce faisant, notre framework XXX fonctionnerait sans probl\u00e8me, mais plus notre code dans notre projet.<\/p>\n<p>Heureusement pour nous, les frameworks s\u00e9rieux sont bien construits et prennent en compte presque tous les sc\u00e9narios. Dans notre cas, log4j dans sa version 2.2.0 propose un compl\u00e9ment r\u00e9tro-compatible avec la version 1.2. Pour que notre projet fonctionne correctement, il nous suffira de l&rsquo;ajouter \u00e0 nos d\u00e9pendances. Ainsi, nous aurons une biblioth\u00e8que suppl\u00e9mentaire pour garantir le bon fonctionnement de notre fameux framework XXX.<\/p>\n<p>&nbsp;<\/p>\n<h2>Probl\u00e9matique de versions<\/h2>\n<p>C&rsquo;est un probl\u00e8me qui se rencontre parfois avec le pr\u00e9c\u00e9dent. L&rsquo;ensemble des frameworks et de leurs versions sont r\u00e9f\u00e9renc\u00e9s sur ce que l&rsquo;on appel des <em>repository<\/em>.<\/p>\n<p>Par exemple, les versions de Spring Core :<\/p>\n<p>[\/et_pb_text][et_pb_image src=\u00a0\u00bbhttps:\/\/www.lena-it.fr\/wp-content\/uploads\/2023\/09\/versions-de-Spring-Core-.png\u00a0\u00bb alt=\u00a0\u00bbversions de Spring Core \u00a0\u00bb title_text=\u00a0\u00bbversions de Spring Core\u00a0\u00bb align=\u00a0\u00bbcenter\u00a0\u00bb _builder_version=\u00a0\u00bb4.22.2&Prime; _module_preset=\u00a0\u00bbdefault\u00a0\u00bb module_alignment=\u00a0\u00bbcenter\u00a0\u00bb custom_margin=\u00a0\u00bb0px||11px||false|false\u00a0\u00bb custom_padding=\u00a0\u00bb0px||||false|false\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb theme_builder_area=\u00a0\u00bbpost_content\u00a0\u00bb][\/et_pb_image][et_pb_text ul_item_indent=\u00a0\u00bb30px\u00a0\u00bb ol_position=\u00a0\u00bboutside\u00a0\u00bb ol_item_indent=\u00a0\u00bb30px\u00a0\u00bb _builder_version=\u00a0\u00bb4.22.2&Prime; _module_preset=\u00a0\u00bbdefault\u00a0\u00bb text_font_size=\u00a0\u00bb16px\u00a0\u00bb header_2_text_color=\u00a0\u00bb#386759&Prime; header_2_font_size=\u00a0\u00bb22px\u00a0\u00bb header_2_line_height=\u00a0\u00bb1.6em\u00a0\u00bb custom_margin=\u00a0\u00bb0px||0px||false|false\u00a0\u00bb custom_padding=\u00a0\u00bb0px||0px||false|false\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb theme_builder_area=\u00a0\u00bbpost_content\u00a0\u00bb]<\/p>\n<ol><\/ol>\n<p>On peut y retrouver un grand nombre d&rsquo;informations, telles que les probl\u00e9matiques de s\u00e9curit\u00e9, les d\u00e9pendances transversales, ainsi que les dates de releases.<\/p>\n<p>Que se passe-t-il quand je veux changer une version d&rsquo;un framework ?<\/p>\n<p>Je vais volontairement partir sur un cas complexe : je veux passer de Spring Core 5.3.30 \u00e0 Spring Core 6.0.12.<\/p>\n<p>Si vous avez suivi le chapitre pr\u00e9c\u00e9dent, vous me direz : \u00ab\u00a0c&rsquo;est super simple, je change dans mon outil de build ma version et hop, le tour est jou\u00e9\u00a0\u00bb.<\/p>\n<p>Dans les cas simples, vous auriez enti\u00e8rement raison, mais malheureusement, dans notre cas, cela ne sera pas aussi trivial.<\/p>\n<p>Avant tout changement de version, vous devez imp\u00e9rativement lire les changelogs associ\u00e9s au framework vis\u00e9. Ces documents sont disponibles sur le site de l&rsquo;\u00e9diteur du framework et contiennent l&rsquo;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.<\/p>\n<p>Cette contrainte, passer en Java 17, peut \u00e0 elle seule casser la totalit\u00e9 de votre stack technique. En effet, qu&rsquo;en est-il des autres frameworks ? Supportent-ils la version 17 de Java ? Et si votre projet est un projet web, qu&rsquo;en est-il des serveurs d&rsquo;applications ? Faudra-t-il aussi les faire passer en Java 17 ?<\/p>\n<p>Je pense que vous l&rsquo;aurez compris, dans mon exemple, on se retrouve avec un magnifique effet avalanche qui affectera tout votre SI.<\/p>\n<p>Contrairement \u00e0 notre probl\u00e9matique pr\u00e9c\u00e9dente, il n&rsquo;y a pas ici de solution simple ou miraculeuse. Il va falloir sonner \u00e0 tous les \u00e9tages du SI : urbanistes, architectes, productions, DevOps, RSSI, &#8230; afin d&rsquo;\u00e9valuer la pertinence ou non de r\u00e9aliser cette migration qui s&rsquo;est transform\u00e9e en chantier de migration<\/p>\n<p>&nbsp;<\/p>\n<h2>Faut-il changer de version<\/h2>\n<p>Question tr\u00e8s sage s&rsquo;il en est. Nous avons pu constater qu&rsquo;un petit changement peut entra\u00eener de gros chantiers.<\/p>\n<p>Diff\u00e9rents cas de figure peuvent se pr\u00e9senter :<\/p>\n<ul>\n<li>Vous changez car il y a un gros probl\u00e8me de s\u00e9curit\u00e9 sur le framework : le changement est imp\u00e9ratif, il faut le faire sauf contre ordre du RSSI qui en assumera les cons\u00e9quences<\/li>\n<li>Vous changez car il y a un changement dans la stack technique : par exemple vous passez de Java 8 \u00e0 Java 20. Dans ce cas de figure, vous n&rsquo;\u00eates pas contraint d&rsquo;aller vite, via de la conteneurisation vous pouvez laisser vivre vos diff\u00e9rentes versions sans entrainer un effet avalanche.<\/li>\n<li>Vous changez car vous faites une refonte de l&rsquo;application : c&rsquo;est le plus simple, vous avez toute libert\u00e9 dans vos choix<\/li>\n<\/ul>\n<p>Hormis les probl\u00e9matiques techniques, n&rsquo;oubliez pas de vous poser les deux questions qui f\u00e2chent :<\/p>\n<ul>\n<li>Quel est votre budget : un changement de version peut co\u00fbter un ou deux jours comme il peut aussi vous en prendre trois cents.<\/li>\n<li>Comment allez vous faire vos validations : avez-vous des outils automatis\u00e9s pour vos tests, avez-vous des plans de tests \u00e0 faire valider par votre MOA. Tout ceci n&rsquo;est pas gratuit ni en temps ni en argent, pensez \u00e0 planifier.<\/li>\n<\/ul>\n<p>Maintenant, pour r\u00e9pondre \u00e0 cette question : Faut-il changer de version de framework ? la r\u00e9ponse devrait toujours \u00eatre oui, sauf si pour vous l&rsquo;application est morte ou doit mourir. En effet, vous n&rsquo;\u00e9chapperez pas \u00e0 la course en avant des stacks techniques, qui sont l\u00e0 pour garantir la s\u00e9curit\u00e9 et la performance de vos projets. Il est, de nos jours, impossible de rester sur une version d&rsquo;un framework pendant plus d&rsquo;un an.<\/p>\n<p>Si je garde la stack Java comme exemple :<\/p>\n<ul>\n<li>Vous avez au minimum une version majeure du Spring par an<\/li>\n<li>Vous avez deux versions de Java par an, dont une majeure (les fameuses LTS) tous les 3\/4 ans<\/li>\n<\/ul>\n<p>C\u00f4t\u00e9 front, si vous faites de l&rsquo;Angular : vous avez une version majeure par an.<\/p>\n<p>Une version majeure signifie que le code de vos applications, parfois m\u00eame leur organisation, changeront \u00e0 cause du framework. Typiquement, votre code risque de ne plus compiler, ou de ne plus fonctionner voir de ne plus passer les analyses qualit\u00e9s.<\/p>\n<p>&nbsp;<\/p>\n<h2>Quand changer de version<\/h2>\n<p>Maintenant que vous avez compris que vous ne pourrez pas \u00e9chapper aux changements de versions, il faut se poser la question du \u00ab\u00a0quand changer de version\u00a0\u00bb.<\/p>\n<p>Disons-le tout de suite, il n&rsquo;y a pas de bon moment ; le plus important, c&rsquo;est de l&rsquo;int\u00e9grer dans votre planification de projet avec un chiffrage acceptable.<\/p>\n<p>Pour planifier une date coh\u00e9rente, le plus simple est d&rsquo;aller regarder sur les sites de chacun de vos frameworks majeurs. Ils ont tous des roadmaps qui sont globalement respect\u00e9es. Prenez la date officielle et ajoutez-y un ou deux mois, histoire de :<\/p>\n<ul>\n<li>Ne pas essuyer les pl\u00e2tres et diff\u00e9rents bugs dans la nouvelle version du framework<\/li>\n<li>S\u2019assurer une marge au cas o\u00f9 il y aurait du retard dans la roadmap du framework<\/li>\n<\/ul>\n<p>Si votre projet dure 6 mois (on parle de d\u00e9lai ici, pas de charge), vous pouvez provisionner 5 \u00e0 10 jours\/homme afin de r\u00e9aliser vos changements de versions. C&rsquo;est un chiffrage moyen qui va d\u00e9pendre de la complexit\u00e9 et de la criticit\u00e9 de votre application.<\/p>\n<p>Ce chiffre sera multipli\u00e9 par trois si votre projet s&rsquo;\u00e9tale sur 1 an. Je vous encourage \u00e0 provisionner 15 \u00e0 25 j\/h pour garantir que vos changements de versions se feront sans \u00e9cueil.<\/p>\n<p>Selon la dur\u00e9e de votre projet, vous n&rsquo;\u00eates pas oblig\u00e9 de faire toutes les migrations en m\u00eame temps. Vous pouvez d&rsquo;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.<\/p>\n<p>&nbsp;<\/p>\n<h2>Comment rester serein<\/h2>\n<p>Pour ceux qui ont connu l&rsquo;informatique des ann\u00e9es 1980, les changements de versions \u00e9taient r\u00e9alis\u00e9s de mani\u00e8re tr\u00e8s lente et r\u00e9fl\u00e9chie.<\/p>\n<p>De nos jours, ces changements sont quasi-quotidiens et ont n\u00e9cessit\u00e9 la mise en place des processus DevOps.Pour attaquer sereinement vos changements de versions dans vos applications il est imp\u00e9ratif d&rsquo;avoir :<\/p>\n<ul>\n<li>Un cycle d&rsquo;int\u00e9gration continu op\u00e9rationnel et pr\u00e9cis<\/li>\n<li>Des tests unitaires, j&rsquo;insiste ici sur le fait que ce sont des tests unitaires<\/li>\n<\/ul>\n<p>S&rsquo;il vous manque d\u00e9j\u00e0 un de ses deux \u00e9l\u00e9ments, ne cherchez pas \u00e0 changer de versions de framework mais commencez plut\u00f4t \u00e0 les mettre en place.<\/p>\n<p>Il est aussi fortement conseill\u00e9 d&rsquo;avoir\u00a0:<\/p>\n<ul>\n<li>Un cycle de d\u00e9ploiement continu<\/li>\n<li>Des tests d&rsquo;int\u00e9grations<\/li>\n<\/ul>\n<p>Dans un monde id\u00e9al, nous devrions tous avoir en plus\u00a0:<\/p>\n<ul>\n<li>Des analyses qualit\u00e9 automatis\u00e9es<\/li>\n<li>Des analyses s\u00e9curit\u00e9s automatis\u00e9es<\/li>\n<li>Des tests de charges coh\u00e9rents<\/li>\n<li>Des recettes utilisateurs outill\u00e9es<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>Conclusion<\/h2>\n<p>Dans un monde de d\u00e9veloppement informatique en constante \u00e9volution, les frameworks jouent un r\u00f4le crucial en acc\u00e9l\u00e9rant les projets, mais les changements de versions posent des d\u00e9fis majeurs.<\/p>\n<p>Notre accompagnement chez Lena IT se r\u00e9v\u00e8le \u00eatre une ressource pr\u00e9cieuse dans ce contexte en constante mutation. Notre expertise en mati\u00e8re de d\u00e9veloppement, de gestion des versions et de planification strat\u00e9gique peut vous aider \u00e0 naviguer en toute confiance \u00e0 travers ces changements. De l&rsquo;int\u00e9gration continue aux tests automatis\u00e9s, en passant par les analyses de qualit\u00e9 et de s\u00e9curit\u00e9, nous vous offrons un soutien complet pour garantir des transitions harmonieuses vers de nouvelles versions de frameworks.<\/p>\n<p>La gestion efficace des changements de frameworks est devenue essentielle, et avec un soutien ad\u00e9quat, les \u00e9quipes peuvent naviguer avec confiance dans ce paysage technologique en constante mutation.<\/p>\n<p>[\/et_pb_text][et_pb_button button_url=\u00a0\u00bbhttps:\/\/outlook.office.com\/bookwithme\/user\/dc85c621afc5486e9afcbe5fef6ee6ef%404bd4bf83-c3d7-40fa-9df4-095be247cf8c\/meetingtype\/30ee0301-bd72-481c-a931-0d288d3d67c7?anonymous\u00a0\u00bb button_text=\u00a0\u00bbPrendre un rendez-vous\u00a0\u00bb button_alignment=\u00a0\u00bbcenter\u00a0\u00bb _builder_version=\u00a0\u00bb4.22.2&Prime; _module_preset=\u00a0\u00bbdefault\u00a0\u00bb custom_margin=\u00a0\u00bb20px||||false|false\u00a0\u00bb global_colors_info=\u00a0\u00bb{}\u00a0\u00bb theme_builder_area=\u00a0\u00bbpost_content\u00a0\u00bb][\/et_pb_button][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introduction Depuis plus de vingt ans maintenant, le monde du d\u00e9veloppement peut compter sur l&rsquo;aide des frameworks. Ces fameuses biblioth\u00e8ques de code, open source ou non, simplifient et acc\u00e9l\u00e8rent la r\u00e9alisation de nos projets informatiques. Cependant, depuis quelques ann\u00e9es, leur utilisation a \u00e9galement \u00e9t\u00e9 source de probl\u00e8mes, comme le framework Struts, qui a pr\u00e9sent\u00e9 une [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":1070,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"","_et_gb_content_width":"","content-type":"","_sitemap_exclude":false,"_sitemap_priority":"","_sitemap_frequency":"","footnotes":""},"categories":[37,39,38,35],"tags":[],"class_list":["post-1068","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-developpement","category-devops","category-numerique","category-technologie"],"_links":{"self":[{"href":"https:\/\/www.lena-it.fr\/index.php\/wp-json\/wp\/v2\/posts\/1068","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.lena-it.fr\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.lena-it.fr\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.lena-it.fr\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.lena-it.fr\/index.php\/wp-json\/wp\/v2\/comments?post=1068"}],"version-history":[{"count":8,"href":"https:\/\/www.lena-it.fr\/index.php\/wp-json\/wp\/v2\/posts\/1068\/revisions"}],"predecessor-version":[{"id":1126,"href":"https:\/\/www.lena-it.fr\/index.php\/wp-json\/wp\/v2\/posts\/1068\/revisions\/1126"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.lena-it.fr\/index.php\/wp-json\/wp\/v2\/media\/1070"}],"wp:attachment":[{"href":"https:\/\/www.lena-it.fr\/index.php\/wp-json\/wp\/v2\/media?parent=1068"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.lena-it.fr\/index.php\/wp-json\/wp\/v2\/categories?post=1068"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.lena-it.fr\/index.php\/wp-json\/wp\/v2\/tags?post=1068"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}