Celui qui déplace la montagne, c’est celui qui commence par enlever les petites pierres – Confucius

Shop Application vient de fêter ses 15 ans ! Il est temps de revoir un peu son look et de le propulser dans le futur.
Le chantier de la refonte est lancé. Tout d'abord graphique et ergonomique puis, dans un second temps, on s'attaquera au modèle de données.

Dérivé d'un osCommerce de 2006 (ne cherchez pas les failles, on est déjà passés dessus depuis longtemps), Shop App dispose de son propre framework très complet, certes, mais loin d'être à la pointe de la technologie.

Plutôt que de réinventer la roue, pourquoi ne pas utiliser un framework open-source ? Comme le disait Maxence Poutord en 2015 : "utilisez un framework PHP".
Au vu de la structure de notre logiciel, on va pouvoir facilement intégrer un framework au coeur de celui-ci pour remplacer les pages une par une.

Commençons donc par définir nos besoins.

Nos besoins

On veut un système de routing suffisamment permissif pour s'adapter à nos routes actuelles : il n'est pas question de changer la façon de travailler de nos clients ni leur casser tous les liens qu'ils auraient mis en favoris par exemple. Il faut donc qu'on conserve les routes telles quelles.

En anticipant un peu la seconde partie de cette refonte, que sera le travail sur le modèle de données, un ORM serait un bel avantage.

Nos collègues développeurs, intégrateurs et techniciens support viennent tous d'univers très différents, et tous ont un parcours qui les distingue. Ce framework devra donc être facile à appréhender, que ce soit au niveau du langage, des concepts et de la structure de fichiers.

Enfin, on sélectionnera le candidat final par son rapport performance/légéreté et sa communauté. L'idéal étant de pouvoir contribuer à l'amélioration de l'outil si besoin est.

Entretien avec les candidats

Les arguments avancés ci-dessous à l'encontre des frameworks qui n'ont pas été retenus sont totalement subjectifs et conditionnés par leur application à notre logiciel. Autrement dit : on se calme, de toute façon on fait ce qu'on veut.

Pour répondre à ces quelques petites contraintes, on a finalement pas mal de possibilités qui s'offrent à nous. Permettons-nous donc de tailler dans le gras.

Ont donc été exclus d'office Symfony et ses dérivés parce qu'il nous aurait fallu commencer par surcharger trop de composants avant même de se mettre à refaire nos pages. On perdrait alors certains avantages du framework et des mises à jour associées. Pas besoin d'aller plus loin dans l'analyse de ce candidat, c'est déjà trop. Accessoirement, j'ai personnellement fait beaucoup de Symfo avant d'arriver à Brest et j'avais envie de voir autre chose. Sortir de sa zone de confort c'est progresser.

Chez nos voisins américains il y a l'équivalent robuste Laravel et son petit frère Lumen. Sauf que le problème précédent se pose également mais qu'en plus ces frameworks sont incompatibles avec nos architectures serveurs. Impossible de donner trop de détails sur celles-ci sans rentrer dans de l'information confidentielle...

Dernier candidat rejeté pour faute grave : Slim. Celui-ci n'est malheureusement pas adapté pour construire un back-end puisqu'il est orienté API (c'est d'ailleurs celui qu'on utilise nous-mêmes pour notre API).

Qui reste t-il sur le bateau ? Phalcon, Yii et CodeIgniter sont encore en lice.

Et c'est finalement CodeIgniter qui remporte la bataille : il répond à tous nos besoins, est léger et performant, dispose de librairies utiles à la demande et, bonus, un moteur de template. Ce qui va nous permettre d'en faire même un peu plus que prévu.

Enfin, coïncidence et c'est ce qui a clairement fait pencher la balance, la version 4 du framework est sortie pendant que je faisais cette étude de marché.

Conclusion

Maintenant que notre nouveau framework est sélectionné on va pouvoir jouer un peu avec, mais ça c'est pour le prochain épisode...