Typo3 : de la version 6.2 à la 7.6

Un logiciel, bien que n’étant pas un être vivant vieillit. Si l’humain voit apparaître des rides, le logiciel lui se fissure à sa manière et multiplie les failles... de sécurité. Il devient moins fiable et de plus en plus inadapté, par son incapacité à intégrer les dernières trouvailles. Quand on est un logiciel, on sait parfois faire tourner les modules de la génération précédente… moyennant quelques petites adaptations. Mais quand on est un module tout jeune et tout fringant, parfois, on n’est pas adapté parfois pour fonctionner parmi les anciens. Disons le tout net, chez les logiciels, les conflits intergénérationnels se règlent bien souvent au prix d’un changement radical qu’on appelle migration.

A la DUN, nous choisissons  pour Typo3 le support à long terme, qui en général court sur 3 ans, à partir de la sortie de la version.
Vous pouvez consulter la carte des versions typo3 sur le site de typo3.org.

La migration d’un logiciel, contrairement à celle des oiseaux, champions du monde de l’aller-retour longue distance, n’a qu’un seul sens : celui de la dernière version.
Les nouvelles versions n’ont d’intérêt que si elles offrent au moins une des caractéristiques suivantes :

• elles intègrent les dernières évolutions techniques  - versions des systèmes, langages, bases de données, et extensions
• elles répondent à des besoins non couverts par la version précédente (amélioration fonctionnelle)
• elles refondent l’interface utilisateur (amélioration ergonomique)

Au final, elles sont plus ou moins complexes, selon le saut technologique opéré.

Au niveau du web, ça donne quoi ? Notre gestionnaire de contenu Typo3, est le logiciel qui permet à nos rédacteurs de créer des pages, les nourrir, les agencer dans le but avoué d’informer le mieux possible nos visiteurs. Typo3 est un logiciel comme un autre : il vieillit. Notre choix à la DUN est celui de la sécurité, du confort utilisateurs et du coût maitrisé.
La sécurité s’obtient en s’assurant le service d’une équipe support qui va corriger les petits dysfonctionnements de notre logiciel - appelé aussi bugs - au fur et à mesure qu’ils seront détectés. Car, ainsi va la vie d’un logiciel : s’il tend toujours vers un mieux technologique, ce mieux s’accompagne inévitablement de coquilles, qui dans les versions mises en production - c’est à dire sur nos serveurs - se doivent d’être mineures. Car avant d’être proposé à l'utilisation de masse, un logiciel passe par différents stades. Il naît alpha, subit une première étape de correction, puis devient bêta, avec une nouvelle étape de correction, et c’est seulement après tout cela qu’il peut entrer en production. Et c’est à ce moment là que commence le support.

Pour ce qui est du confort utilisateur, il est  évalué avant chaque migration par nos soins, sur une installation de test. Nous devons nous assurer que les fonctionnalités utilisées par nos rédacteurs sont reconduites ou qu’une alternative est proposée. S’il ‘y a pas d’alternative, le  prestataire qui nous accompagne pour la migration sera chargé de la pérennité de la fonctionnalité souhaitée. En clair, c’est le prestataire qui fera les développements manquants.

Pour ce qui est du coût, il est maîtrisé s’il se répartit au fil des ans. Ainsi, il est beaucoup plus raisonnable de migrer de version majeure en version majeure sans sauter une seule version, plutôt que de faire de grand saut technologique qui sera toujours bien plus coûteux.