Quelques bonnes raisons (et pas uniquement techniques !) de remplacer votre vieux framework

Il est parfois dit que l’on ne mesure la qualité d’une architecture technique que des années après, lorsque le poids de l’existant aura eu tout loisir de mettre à mal la souplesse du design technique. Certes, me direz-vous, les agaçants problèmes liés à un existant obsolète sont parmi les plus récurrents pour toutes les architectures techniques, Web ou non-Web. Ce à quoi je vous répondrais que je suis bien d’accord, mais que nous traversons sans doute l’ère du Web durant laquelle le problème est le plus critique, car les architectures commençant à dater (qui ont, disons, 5 ou 6 ans) ont été construites à une époque où les frameworks Web que je qualifierais de « modernes » n’existaient pas encore sous une forme stable.

Six ans d’âge pour un site Web, ce n’est pas une quantité absurde à l’échelle de la vie d’une marque ; et pourtant les avancées technologiques et qualitatives ayant eu lieu sur ce quart de l’existence du Web ont redéfini entièrement la manière d’appréhender les architectures modernes, qui s’appuient maintenant sur des frameworks qui sont désormais purement construits pour le Web (et ça change tout !)

Tout aussi récurrents que les problèmes techniques, sont les problèmes économiques, et c’est là le fond pragmatique du problème : vous trouverez bien souvent chez le client une MOE qui pousse à l’abandon de pans entiers de l’existant au profit de solutions plus modernes, et une MOA qui cherche un ROI dans tout ça (à quoi bon tout refaire, puisque ça marche déjà ?)

Très chers MOA, je ne pourrais pas plus être d’accord avec vous : il n’y aurait aucun intérêt à tout casser pour refaire du neuf, si les résultats d’une telle refonte n’étaient pas bénéfiques pour votre approche de la qualité projet aussi !

Apports fonctionnels

Les frameworks dits « modernes » ayant été initialement construits sur des architectures dédiées aux besoins du Web, leurs extensions vont non seulement vous mâcher le travail jusqu’au front, mais même jusqu’à la fonctionnalité Web en elle-même. Là où les frameworks obsolètes vous proposaient un outillage permettant une intégration de SOAP, de XML-RPC, de Notes, … les frameworks récents vont jusqu’à vous proposer des plugs-in de commentaires, d’authentification/inscription d’utilisateurs, d’interactions sociales de votre choix entre vos utilisateurs, … Cette différence majeure explique en grande partie les différences dramatiques de coûts de développement et de maintenance entre les deux âges.

Cas réel : un client ayant des problèmes de spams dans ses commentaires, nous a demandé d’installer un captcha sur tout son parc techniquement hétéroclites de sites Web. Le même consultant a réalisé l’évolution sur les plateformes obsolètes (sous Java/Struts1) et les plus récentes (sous PHP/Symfony). La fonctionnalité existant sur Symfony sous la forme d’un plug-in, l’intervention aura duré 1h à 2h, contre… 4 jours sur la plateforme ancienne !

Par corollaire, dans ce monde de Web ouvert et d’APIs, votre solution saura donc s’interfacer de manière toujours actuellement pertinente avec les outils externes dont vous pourriez avoir besoin. Je pense notamment à la souffrance des MOE en apprenant l’abandon de l’API Facebook Connect l’année dernière, ou de l’API Google Translate cette année. Si le framework est dépassé, et que tout a été développé à la main, il faudra soit re-développer cette fonctionnalité de zéro, soit laisser le site poursuivre son existence avec des fonctionnalités (au moins partiellement) cassées.

Cas réel : il nous a été demandé plusieurs mises à niveau de Facebook Connect suite à son abandon, notamment sous Symfony ou Drupal, où les plugs-in en question ont été mis à jour à temps par leurs développeurs. Coût de l’opération : environ une 1/2 journée, tests et déploiement compris. Je vous laisse deviner le coût de redéveloppement manuel de zéro de cette fonctionnalité qui peut être massive selon son intégration dans le site…

Nouveau corollaire, pour cause de parallèle historique dans la qualité des solutions : Lucene n’était pas du tout mature il y a six ans, Solr n’existait pas, et les deux sont maintenant des incontournables. Mieux : la nouvelle génération de moteurs de recherche arrive, et nos premières intégrations de l’outil Elastic Search (et de son approche « standalone ») nous ont laissés très impressionnés. Au mieux, il y a six ans, vous avez opté pour l’adoption d’un outil imparfait, qui a évolué plus ou moins bien depuis (si vous aviez choisi Lucene, vous êtes bien chanceux !) ; au pire, vous avez développé vous-mêmes un pseudo-Lucene, qui bien logiquement, ne peut pas arriver à la cheville de la finition des outils existants (notamment en terme d’apprentissage automatique). Dans les deux cas, un framework moderne vous apportera une intégration native avec les outils de recherche d’aujourd’hui, qui sont devenus fiables, stables et pérennes.

Apports techniques dans le coeur de la solution

Évidemment, s’il y a un attrait technique particulièrement évident, et cité de facto par la MOA, c’est bien la performance. Au dela des milli-secondes, la raison est évidente : les solutions proposées il y a 8 ou 10 ans étaient pensées et adaptées pour un « scaling » d’il y a 10 ans, et ne sont pas censées tenir la charge inhérente à la fréquentation du net en 2011 ; les solutions modernes, quant à elles, correspondent aux caractéristiques de charge du Web actuel.

Une autre évidence est l’état de maintenance de la solution. Avec l’arrivée des solutions pensées pour le Web, la pérennité des frameworks anciens a beaucoup souffert, et beaucoup d’entre eux ne jouissent plus de mises à jours satisfaisantes. Et il n’y a rien de plus douloureux qu’une solution buggée sans espoir de corrections…

De plus, il y a fort à parier que votre solution ne respecte pas les patrons de conception (design patterns) qui font autorité pour garantir une maintenabilité de la solution qui soit maximale. Ces modèles n’ayant pas pour la plupart une utilité propre au Web, leur existence et leur popularité sont antérieures à ces six dernières années ; toutefois, l’intégration de ces modèles dans les solutions Web était à l’époque très chaotique, et l’outil encadrait souvent mal ces bonnes pratiques ; le résultat est donc aujourd’hui une plateforme chargée de contournement et de violation des modèles. Pour donner un exemple, le célèbre modèle MVC permet de séparer notamment le code métier ; tout changement ou bug dans les process métier est donc beaucoup plus facilement retrouvable.

Enfin, les solutions anciennes se trouvent être particulièrement faibles sur le front de la sécurité, proposant rarement nativement des contournements de failles XSS (injection de code SQL malicieux, par exemple), qui est aussi un incontournable natif dans les solutions modernes. Également, le framework moderne vient nativement avec des protections contre l’accès aux répertoires non-sécurisés, contre la soumission de formulaires de masse, contre les tentatives d’attaques brute-force sur les comptes utilisateurs, etc… qu’il faut développer à la main (ou dont il faut souffrir l’absence) sur les solutions plus anciennes.

Outillage technique

Évidemment, les manques quant à l’outillage natif de vos développeurs se ressentent essentiellement dans leur facilité/rapidité de réalisation ; toutefois un outillage insuffisant peut parfois mener à des pertes de temps très conséquentes, voire même dans des pertes définitives de qualité.

Dans la famille des pertes de temps systématiques, les frameworks modernes viennent souvent avec des scripts d’installation d’environnement, permettant à tout nouvel environnement installé (nouveau venu dans l’équipe, mise à jour matérielle, mais aussi nouveau serveur de production, de recette, ou de préprod) de ne pas prendre l’habituelle journée (voire plus) incompressible perdue avant même que la première opération utile ne soit réalisée.

Cas réel : je suis notamment toujours surpris de la rapidité avec laquelle les développeurs PHP/Symfony sont opérationnels sur un projet auquel ils n’ont jamais touché ; leur temps d’installation d’environnement dépasse rarement l’heure, tout au plus !

Et dans la famille des pertes brutes de qualité, il est difficile de faire une gestion et une amélioration continue de la qualité applicative de la plateforme, sans avoir un système de gestion d’alertes qui soit non seulement fiable (tous les problèmes sont effectivement remontés), mais aussi qui facilite le travail du développeur dans la résolution du bug. Le manque de ce type d’outil résulte au mieux en un système qui ne vous fait perdre que du temps en correction de bug, mais le plus souvent va jusqu’à ne pas vous permettre d’être certain qu’il n’y a aucun problème silencieux sur votre plateforme !…

Evidemment, bien que ces deux outils représentent déjà deux progressions frappantes, ils ne représentent qu’une fraction de l’outillage essentiel des frameworks modernes, qui simplifie l’utilisation globale de l’écosystème.

Gestion de projet technique : intégration continue

Évidemment, les tests unitaires et les tests de non-régression ne datent pas d’hier : sur une solution de client lourd, les développeurs peuvent aussi développer des tests à chacune de leurs réalisations, pour pouvoir exécuter tous les tests à échéance régulière, et s’assurer que chaque fonctionnalité est toujours en état de marche continuellement.

Les tests fonctionnels ont mis plus de temps pour voyager du client lourd au client Web, puisque le soft doit simuler des clic et des actions directement sur l’interface Web dans le navigateur, pour vérifier que le site fonctionne toujours comme il est attendu quel que soit le scénario de l’utilisateur. Aujourd’hui, les solutions qui industrialisent le jeu de tests, mais aussi la saisie de ces tests sur une interface, arrivent à une maturité qui ne permet plus de les ignorer (avez-vous entendu parler de Selenium ?)

Toutefois, s’il est quelque chose qui est propre au Web, c’est ce fameux déploiement universel : déployez vos évolutions ou vos résolutions de bug une fois, et tous vos utilisateurs ont instantanément la modification ! Une magie par rapport à l’industrie du client lourd…

Le concept d’intégration continue permet de laisser un outil extérieur (souvent Jenkins, ex-Hudson) avoir la main sur les scripts de mise en production (et aussi de mise en pré-production, en recette, etc) pour pouvoir réaliser ces déploiements en un clin d’oeil, depuis une interface Web qui simplifie la vie du chef de projet technique. Et non seulement vos déploiements seront-ils lancés de manière enfantine, mais en plus ils seront automatiquement testés par cette solution AVANT de permettre la finalisation du déploiement !

Ainsi, si vos développeurs rédigent des tests unitaires de bonne qualité, que vos recetteurs rédigent des tests fonctionnels exhaustifs, jamais bug ne sera vu par votre environnement de production !

Cette notion d’intégration continue est devenue tellement basique dans la gestion de projet Web, qu’il n’existe plus de framework moderne aujourd’hui qui ne soit pas nativement interfaçable en quelques clics avec les solutions d’intégration continue les plus usuelles…

De quoi secouer fortement la qualité de votre produit !

Conclusion

Évidemment, la limite entre framework obsolète et framework moderne n’est pas franche, et il existe une palette entière de nuances de frameworks perfectibles, pour lesquels la question d’une refonte se pose réellement. Rien ne vous interdit donc de mener (ou de faire mener) une mission d’étude de votre existant, pour évaluer si votre plateforme est préhistorique, ou juste un tout petit peu rouillée par rapport à ce qui se fait aujourd’hui.

Toutefois, le message est là : il ne faut surtout pas minimiser l’impact d’une solution réellement dépassée. La refonte complète sera certainement coûteuse, mais elle fait partie d’une solution à long terme que (si vous suivez l’avancée habituelle des réalisations techniques de votre projet) vous ne regretterez pas, autant en terme d’efficacité que de qualité.

Si vous hésitez encore, alors je vais vous donner un coup de pouce : pour ce type de refonte, le timing pour la pérennité ne me semble jamais avoir été aussi bon qu’aujourd’hui. La marche de « framework purement technique » à « framework fonctionnel dédié au Web » a été passée, ce qui nous donne de bonnes chances de mieux survivre à la prochaine migraine à survenir dans 6 ans !