Chez Imagile, même si nous sommes spécialisés dans le développement web depuis 2001, nous ne connaissons pas pour autant l’ensemble des technologies employées du web. Nous maîtrisons, c’est-à-dire que nous avons déjà réalisé des développements conséquents (reprises d’existants, nouveaux projets, migrations de versions majeures…) dans quelques langages et frameworks dont voici la liste :
| Langages | Framework et outils | CMS |
|---|---|---|
| PHP |
Symfony Laravel CakePHP |
WordPress |
| Ruby | Ruby on Rails | |
| Javascript | Vue.JS |
Si vous utilisez des langages comme Java ou Python, nous ne pourrons pas vous aider dans votre audit, à moins que vous ne souhaitiez repenser et développer une nouvelle version de votre outil sous un langage et avec un framework présenté ci-dessus.
La quantité de plugins utilisés et la qualité du code de l’application ont un énorme impact sur le degré de difficulté de la migration. Au-delà de la version du framework utilisé par votre application il est donc nécessaire d’en auditer le code pour établir un listing des plugins indispensables et facultatifs et un plan de migration. Il n’est pas rare non plus de devoir remplacer des plugins ou modifier une partie conséquente du code de l’application dans la mesure où un plugin peut avoir évolué considérablement entre ses différentes versions.
| Framework | Version minimale actuelle |
|---|---|
| Ruby on Rails | 5.2 |
| Symfony | 3.4 |
| Laravel | 6 |
| CakePHP | 3 |
| Vue.JS | 2 |
Si la version de votre framework est inférieure à celle-ci, il faut vite faire quelque chose…
La politique de support varie en fonction de chaque framework. Ainsi, le principe de LTS (Long-Term Support) permet de s’assurer qu’une version exploitée sera maintenue pendant un temps relativement long sans mise à jour non-rétrocompatible. C’est le cas pour Symfony, Laravel (depuis peu) et Ember. Qui plus est, Symfony publie un calendrier des versions bien à l’avance. Ruby on Rails ne fonctionne pas de la même manière : dès qu’une version majeure sort, la version précédente n’est plus maintenue, hormis pour les patchs de sécurité. Pour CakePHP, alors que la date de la version 4 est désormais connue, la version 2 est annoncée maintenue pour encore 18 mois…
De manière générale, il faut compter sur 2 voire 3 ans de stabilité d’une version avant qu’elle ne soit obsolète.
Ruby est le langage utilisé par le framework Ruby on Rails. La version de Ruby la plus vieille encore maintenue est la 2.5. La plus récente est la 2.7 et une version majeure, la 3.0, est en cours d’élaboration.
Ruby on Rails a beaucoup évolué dans ses premières versions avec des changements majeurs entre chaque. Depuis la version 4, le passage aux versions suivantes est plus facile car il y a peu de changement. Les migrations les plus fastidieuses sont celles concernant les versions 1, 2 et 3.
| Version de départ | Version d'arrivée | Degré de difficulté |
|---|---|---|
| 2.3 | 3.2 | XXXX |
| 3.2 | 4.2 | XXXX |
| 4.2 | 5.2 | XX ou XXX selon l’application |
| 5.2 | 6 | X ou XX selon l’application |
PHP est un langage qui a ces dernières années grandement évolué, d’abord de 3 à 4, puis de 4 à 5 et enfin de 5 à 7. Depuis la version 7, les changements sont moins laborieux et cassent moins de choses.
Les mises à jour du framework Symfony sont très cadencées et on peut savoir à l’avance quand programmer les montées de versions. Ce framework respecte à la lettre le principe du versioning sémantique, il est donc possible de savoir à quoi s’attendre en termes de charge de travail et d’impact entre deux numéros de versions.
| Version de départ | Version d'arrivée | Degré de difficulté |
|---|---|---|
| Version mineure | Version mineure d'une même majeure | X |
| Version majeure | Autre version majeure | XX ou XXXXX selon la version |
Le framework CakePHP possède plusieurs versions à la longévité record, la 1.3 et la 2. Le passage de la 1.3 à la 2 correspond principalement à du renommage de fichiers et de fonctions. En outre, il existe un plugin facilitant la migration. Par contre, passer de la 2 à la 3 nécessite quasiment une réécriture complète de l’application, la structure du framework ayant changé en profondeur pour s’adapter aux évolutions apportées par PHP et son écosystème.
| Version de départ | Version d'arrivée | Degré de difficulté |
|---|---|---|
| 1.3 | 2 | XX |
| 2 | 3 | XXXXXXXXXX |
| 3 | 4 | X |
Les mises à jour automatiques de version mineure, apparues dès 2013, permettent d’être protégé dès qu’une faille est découverte. Il est cependant nécessaire de réaliser les mises à jour des versions majeures et des plugins manuellement.
De plus, si WordPress attache une grande importance à la rétro-compatibilité, ce n’est pas du tout le cas de la majorité des plugins. Il est nécessaire de réaliser un listing des plugins, des thèmes et de leurs versions ainsi que du code personnalisé avant de se prononcer sur l’ampleur des travaux de mise à jour.
React, Angular, Vue.JS, Ember, pour ne citer que ces plus connus, nombreux sont ces frameworks javascript à s’être fait une place dans le milieu du développement web.
Malheureusement, ces technologies étant jeunes, elles sont très changeantes. Les versions changent souvent, au risque de ne plus être compatibles avec un certain nombre de plugins, quand il ne s’agit pas d’un changement profond des bases du framework. Angular 2 par exemple n’a plus grand-chose à voir avec Angular 1 tellement la refondation s’apparente à un nouveau framework. Si l’on pense migrer de l’un vers l’autre, on peut tout aussi bien s’autoriser à migrer vers un tout autre framework.
Alors que sur les frameworks PHP ou Ruby nous pouvions nous attendre à une stabilité de deux à trois ans pour une version majeure, il n’est pas rare de procéder à des mises à jour impactantes plusieurs fois par an dans une application javascript. On comprend alors aisément le besoin de ne pas dépendre de trop de plugins externes au framework utilisé, même si dans le cas de React c’est quasiment impossible puisqu’il est plus une bibliothèque de création d’interfaces qu’un framework à proprement parler.
Le meilleur moyen pour sécuriser et faire évoluer son application web est de réaliser un audit technique. Faut-il procéder à des mises à jour ? Les développements ont-ils été réalisés dans les règles de l’Art ? Des tests unitaires permettent-ils d’assurer une pérennité de votre outil ?
Imagile est en mesure de vous accompagner en procédant à cet audit dont le rapport ne se contente pas de dresser un état des lieux technique mais également de proposer des plans de maintenance en fonction de votre budget et de votre stratégie d’entreprise.