Pour une agence web, il n’est pas inhabituel de se voir confier le site web actuel d’un nouveau client à des fins de maintenance de site web ou d’hébergement. Parfois, celui-ci est basé sur un langage ou une technologie que les développeurs connaissent bien, et d’autres fois, moins. Mais, peu importe la qualité du code, il y aura dans tous les cas des questionnements et une réflexion à mener. D’autant plus si la technologie utilisée est peu ou pas connue des développeurs et si, par-dessus le marché, le CMS qui l’accompagne a été conçu sur mesure pour les besoins du client que celui-ci n’est aucunement documenté.
Péniblement, au départ. Évidemment, si vous ne connaissez pas du tout la tech en arrière, ce serait une bonne chose de suivre au moins une formation de base sur celle-ci, afin de savoir un peu par où commencer. Heureusement, les connaissances en programmation sont hautement transférables entre différents langages et, généralement, la logique de programmation reste globalement la même. Alors, viendra rapidement la partie exploration. Installation locale du projet par les développeurs, tests de simples de modification, recherche des différentes infos, exploration du CMS, etc.
À un moment ou à un autre, vous aurez des demandes de modifications et de maintenance de site web de la part du client. Il y aura alors des décisions à prendre. Si ces demandes sont simples, ça ira encore, vous serez sûrement capable de les faire dans un temps relativement raisonnable, surtout après la phase d’apprentissage.
Mais qu’arrive-t-il lorsque ces demandes sont plus complexes ?
Il reste toujours la possibilité de continuer à travailler avec ce qui existe déjà. Mais le client voudra probablement savoir combien de temps le développement de ses demandes prendra et surtout combien cela lui coûtera. Le chargé de projet vous demandera alors de fournir une estimation du tout. Le résultat ? Une estimation plus onéreuse qu’escomptée. On peut essayer de la justifier : c’est une nouvelle tech, un nouveau langage, il n’y a pas de documentation, le CMS actuel ne le supporte pas sans développement supplémentaire, etc… Mais finalement, la raison importe peu, ce qui compte, ce sont les chiffres à côté du signe $. Finalement, à chaque nouvelle demande, et le client en a ! Le temps de développement est largement plus long que s’il s’agissait d’une technologie mieux maîtrisée.
Compte tenu des difficultés rencontrées avec le projet actuel du client, et les projets futurs de ce dernier, il devient très vite évident qu’il faut simplifier le projet actuel. Mais si le site est plutôt gros et complexe, s’il n’est pas un simple site vitrine, cela peut rapidement devenir un gros chantier. Peut-être même trop gros pour pouvoir être fait d’une seule traite et peut être trop dispendieux si le tout doit être accompli en une seule fois. Alors, une alternative s’impose : par exemple, supprimer le CMS actuel et en mettre en place un nouveau, avec une API auquel le frontend pourra se connecter et récupérer les informations. Cela permet donc de réduire le travail à faire, puisque le front doit être relativement peu touché, mais c’est un peu plus de travail du côté CMS : tout le contenu doit être transféré, la mécanique et les fonctionnalités spécifiques doivent être programmées et intégrées, mais surtout, l’API doit être conçue et programmée avec pour objectif de limiter les efforts en front et de faciliter le développement de nouvelles fonctionnalités à venir et de la maintenance du site web.
Un changement de CMS implique un certain nombre de choses. En travaillant le nouveau CMS HubSpot, WordPress ou autre, et l’API qui va avec, il serait pertinent de rendre le tout le plus indépendant possible du frontend. Aussi, pour éviter un gros travail au niveau du SEO et des redirections, on tentera de conserver autant que possible la structure existante des pages.
Alors qu’on avance du côté “backend”, il faut aussi se pencher sur le front, afin d’aller chercher les infos du back via l’API. Il faudra peut-être retravailler le routeur ou en implémenter un autre mieux adapté ; mettre en place un système d’authentification ou conserver l’ancien pour le moment, avec des petits tours de passe-passe pour simplifier le travail à faire ou pour éviter de devoir retravailler des sections qui n’ont pas besoin d’être retravaillées à court terme. Et tant qu’à être dans ce code, effectuer un peu de nettoyage et de simplification, surtout si vous allez vous en servir comme référence pour refaire un frontend dans le futur. Ce “hack” mis en place temporairement pour régler un problème, sur lequel “je compte définitivement y revenir plus tard”, eh bien peut-être est-il souhaitable d’envisager une solution propre à la place pour éviter d’avoir à implémenter un correctif un peu malsain dans la nouvelle API. En travaillant sur les gabarits en front pour les brancher à la nouvelle API, vous trouverez assurément des anciennes fonctionnalités qui ont simplement été désactivées, mises en commentaire, bref des vestiges de code longuement oubliés. Pouf, vous le supprimez : c’est ainsi plus simple que de s’y référer lors de la prochaine refonte.
Enfin ! Vous avez fini de refaire le backend et de retravailler le front pour qu’il s’y connecte. Vous l’avez déployé, mais sans surprise, quelques points vous ont échappé. Ça arrive, surtout dans les sites complexes, sans documentation, et avec un code et CMS custom et ésotérique. Au début, vous passerez un peu de temps à revenir sur le tout, corriger des bugs et adapter le CMS aux attentes du client, avec tout ce qu’il imaginait pour son CMS tout neuf. Et vous pourrez enfin vous mettre à travailler sur les nouvelles fonctionnalités que le client vous a demandées ! Avec un front un peu plus simple, nettoyé, et surtout que vous maîtrisez davantage, maintenant que vous avez dû passer au travers de celui-ci pratiquement au complet, vous pourrez mettre le tout en place.
Et puisque les fonctionnalités sont principalement implémentées en back, peu importe le front, elles seront plus ou moins transférables d’un front à un autre. Ce qui nous amène finalement à cette fameuse refonte.
Mais comme c’est merveilleux ! Puisque vous avez construit votre backend indépendamment du front, et que vous aviez prévu ceci, vous aurez donc la possibilité de refaire le frontend dans votre technologie de préférence ! Peut-être en React ? Qui sait ? En tout cas, React est très apte à se connecter à un API pour récupérer les informations nécessaires, et ça tombe plutôt bien avec votre propre API. React, c’est moderne, au goût du jour, et bien supporté. Vous commencerez ainsi à réimplémenter des fonctionnalités similaires à votre ancien front. Vous vous baserez probablement sur le routeur précédent, par exemple, puisqu’il y aura probablement un certain nombre de pages qui resteront les mêmes. Une page d’accueil, une page à propos, une page nous contacter, il est rare de retrouver un site sans celles-ci. Puis, vous irez dans les pages qui sont mécaniquement un peu plus complexes et reprendrez possiblement en partie la logique d’affichage ou de traitement que vous aviez précédemment. Peut-être nettoyer un peu le tout, mais normalement, vous êtes déjà passé par là une fois, donc pas particulièrement besoin de réinventer la roue. Même si le langage diffère, il y a de bonnes chances que la logique de la programmation derrière soit encore la même, en général, même s’il faudra peut-être des adaptations spécifiques à la technologie que vous aurez choisie, ainsi que par rapport au redesign ou à la maintenance du site web.
Finalement, avec une bonne planification initiale de votre API et de votre CMS, vous devriez avoir ouvert la voie à une refonte du front plus facile. Les avantages seront nombreux : vous devrez alors principalement appeler les mêmes endpoints, vous connaitrez déjà la structure du projet et vous aurez en tête le feedback du client avec les améliorations qu’il souhaitait sur l’ancien site et sur le nouveau.
Un des défis principaux sera de réorganiser le CMS et les informations envoyées par l’API de la bonne façon. Parce qu’il est fort possible que lors du redesign, des pages changent, des fonctionnalités soient ajoutées, retirées ou modifiées. Sinon, ce serait trop simple, n’est-ce pas ? Si votre API n’est pas conçue de manière trop monolithique, cela devrait être relativement simple de déplacer certaines choses d’un endroit à l’autre, mais globalement, il y aura tout de même un peu de travail à faire. Aussi, vous aviez probablement dû implémenter quelques workaround afin de coïncider avec l’ancien frontend, mais maintenant, vous avez aussi l’occasion de retravailler vos to-dos qui trainent ici et là et de faire les fonctionnalités de la bonne manière cette fois-ci.
Finalement, vous arrivez au bout du projet. Il est déployé. Les visiteurs ne voient que du feu, ils ne savent aucunement que le tout nouveau site avait déjà vu plusieurs modifications de son backend dans les mois précédents. Et votre client a, en tout cas on l’espère, un site à son goût, avec un CMS sur lequel les développeurs n’ont pas peur de prononcer le nom du projet.
Pour un coup d’pouce, n’hésitez pas à faire appel à nos experts du design et du développement de site web pour vous accompagner dans votre aventure numérique!