Service

Refonte de site web
au Québec

Un site ou une application qui existe déjà, remis sur des bases tenables. Je mesure d'abord, je tranche ensuite, et je garde ce qui rapporte.

Une refonte de site web consiste à reconstruire un site existant sans jeter ce qui fonctionne déjà. Je relève d'abord l'état réel du site, sa vitesse, son indexation et ses adresses, je tranche entre corriger et reconstruire, puis je bascule en redirigeant chaque page. Les mêmes mesures sont refaites après.

Le problème que ça règle

Le déclencheur d'une refonte est rarement une panne. Le site fonctionne, il ne rapporte rien, et personne ne sait dire pourquoi. Il met du temps à s'afficher sur un téléphone, le formulaire arrive dans une boîte que plus personne ne relève, le gestionnaire de contenu réclame une mise à jour à chaque connexion, et modifier une phrase demande d'appeler quelqu'un qui a quitté l'entreprise il y a deux ans. Chaque symptôme pris seul semble mineur. Ensemble, ils font un actif qui coûte de l'argent et n'en rapporte plus.

Le deuxième cas est plus sournois : le site est récent, il est joli, et Google l'ignore. J'ai vu des pages entières absentes de l'index parce que leur contenu n'existait qu'après l'exécution du JavaScript, des titres identiques recopiés sur trente pages, un fichier de configuration qui interdisait aux robots exactement ce qu'il fallait leur montrer. Un site invisible n'a pas un problème de design, il a un problème de plomberie, et on ne le règle pas en changeant les couleurs.

Le troisième cas touche les applications plutôt que les sites. Le code a quelques années, les bibliothèques dont il dépend ne sont plus maintenues, il n'y a pas de tests, et chaque correction en casse une autre ailleurs. Le réflexe est de tout réécrire. C'est presque toujours le choix le plus cher et le plus risqué, parce qu'une réécriture complète efface aussi les règles de métier que personne n'avait documentées et que le vieux code appliquait sans le dire.

Ce que ce n'est pas

Un mandat mal orienté coûte plus cher à tout le monde qu'un mandat refusé au premier appel. Voici donc ce que je ne vends pas, et ce que je dis quand la demande ne colle pas avec ce que je sais faire.

  • Ce n'est pas un rafraîchissement graphique. Si votre site convertit et que le seul reproche qu'on lui fait est de paraître vieux, changer la typographie et les couleurs coûte une fraction d'une refonte. Je le dis au premier appel, quitte à ce que le mandat devienne trois fois plus petit.
  • Ce n'est pas une réécriture systématique. Tout jeter est la réponse qui se vend le mieux et qui se justifie le moins souvent. Je mesure d'abord ce qui fonctionne, et il arrive que le verdict soit de garder la base existante et de corriger quatre choses.
  • Ce n'est pas un abonnement de référencement. Je corrige dans le code ce qui empêche vos pages d'être indexées et lues, puis je vous montre comment le vérifier vous-même. Je ne vends ni forfait mensuel ni promesse de position, parce que personne ne peut garantir un classement chez Google.
  • Ce n'est pas une migration vers un outil dont on ne sort plus. Si je livre, vous devez pouvoir partir : le code vous appartient, les données s'exportent, et rien d'essentiel ne repose sur une licence qui serait à mon nom.
  • Ce n'est pas une agence. Pas d'équipe, pas de sous-traitance, pas de chargé de projet entre vous et le code. Je prends donc peu de refontes lourdes en parallèle, et je dis quand mon calendrier est plein plutôt que d'étirer le vôtre.
  • Ce n'est pas un audit en cinquante pages qui finit dans un tiroir. Un diagnostic que personne ne transforme en correction ne vaut rien. Je livre le constat et le correctif, ou je passe mon tour.
  • La revue de code n'est pas un tampon d'approbation. Quand on me demande de juger une base de code avant un investissement, une embauche ou la reprise d'un projet, j'écris ce que je vois, y compris quand ça contredit ce que la personne qui paie espérait lire.

Ce que vous recevez

Le livrable n'est ni une maquette ni un rapport. C'est un logiciel qui tourne, avec ce qu'il faut autour pour qu'il continue de tourner le jour où je ne suis plus au dossier.

  • Un diagnostic écrit de ce qui bloque, classé par ce que ça coûte de le laisser en l'état
  • Le site ou l'application remis en service sur des bases tenables, sans coupure visible pour vos visiteurs
  • Vos adresses conservées ou redirigées une par une, pour ne pas jeter le référencement déjà acquis
  • Du contenu présent dans le HTML servi, et pas seulement après exécution du JavaScript
  • Les mesures avant et après, sur les mêmes pages et avec les mêmes outils
  • Les dépendances remises à jour, le code mort retiré, et des tests là où une erreur coûterait cher
  • Le dépôt à votre nom, avec l'historique complet et les décisions documentées
  • Une revue de code écrite quand le mandat s'arrête au diagnostic : constats, risques, et l'ordre dans lequel les traiter

L'outillage reste le même d'un projet à l'autre. Une pile réduite se maintient et se transmet ; une pile choisie pour être à la mode se paie deux ans plus tard, quand plus personne ne veut y toucher.

  • Django
  • React
  • TypeScript
  • PostgreSQL
  • Vite
  • Tailwind CSS

Comment ça se passe

Toujours dans cet ordre, et vous voyez sortir quelque chose de chaque étape. Personne ne disparaît trois mois pour revenir avec une surprise.

  1. Mesurer avant de toucher à quoi que ce soit

    Vitesse relevée sur un vrai téléphone et pas sur une machine de bureau reliée en fibre, pages réellement indexées et pas seulement soumises, contenu présent dans le HTML avant que le navigateur exécute la moindre ligne, erreurs qui remontent déjà en production. Sans ce point de départ écrit, plus personne ne pourra prouver que la refonte a servi à quelque chose, et c'est exactement pour ça que la plupart des refontes ne le prouvent jamais.

  2. Trancher entre corriger et reconstruire

    La question se tranche sur des faits : est-ce que le projet démarre sur ma machine, est-ce que le code se lit, est-ce que les bibliothèques existent encore, est-ce que les données sortent. Je donne le verdict avec les raisons et l'écart de coût entre les deux chemins, puis vous décidez. Il m'arrive de recommander de garder l'existant, et ça retire du travail de mon propre devis.

  3. Garder ce qui rapporte déjà

    Inventaire des adresses qui reçoivent du trafic, des pages qui remontent dans les résultats, des formulaires qui apportent réellement des demandes. Le plan de redirection s'écrit avant la première ligne de code, pas le matin de la bascule. C'est le point précis où les refontes perdent leur référencement, et c'est une perte qu'on ne rattrape pas en trois mois.

  4. Reconstruire par morceaux visibles

    On avance section par section, sur un lien de préproduction que vous pouvez ouvrir n'importe quand. Vous voyez la refonte se faire au lieu d'attendre une grande révélation, et les désaccords se règlent quand ils coûtent une heure plutôt qu'un mois.

  5. Basculer sans coupure

    La bascule se prépare : même code, mêmes données, même configuration tournent sur la préproduction depuis des semaines. Le jour venu, on redirige, puis on surveille les erreurs et les adresses introuvables pendant les jours qui suivent, parce que c'est là que sortent les liens que personne n'avait recensés.

  6. Remesurer, puis passer la main

    Les mêmes mesures qu'à la première étape, sur les mêmes pages, avec les mêmes outils. Ensuite, soit on continue par petites tranches, soit vous repartez avec le dépôt, la documentation et de quoi confier la suite à quelqu'un d'autre. Les deux me vont.

Ce que ça change une fois en ligne

Le mot refonte recouvre deux mandats très différents, et les confondre coûte cher. Il y a la refonte de façade, où le contenu et les adresses restent en place et où seule la présentation change. Et il y a la refonte de fond, où on remplace ce qu'il y a dessous : le socle technique, la structure des données, la manière dont les pages sont produites. La première se voit tout de suite et ne change presque rien aux résultats. La seconde ne se voit pas et change tout. Beaucoup d'entreprises paient la première en croyant acheter la seconde.

Ce qui se perd le plus souvent dans une refonte, ce n'est pas du contenu, ce sont des adresses. Chaque page qui change d'adresse sans redirection abandonne son ancienneté, les liens que d'autres sites lui avaient faits et la position qu'elle occupait. Le tableau des redirections est la partie la moins gratifiante du travail et celle qui décide du résultat. Je l'écris avant de commencer et je le vérifie ligne par ligne après la bascule.

La performance, ensuite, ne se mesure pas là où on la regarde d'habitude. Un site testé sur un ordinateur de bureau relié en fibre affiche toujours de bons chiffres. Le vrai test, c'est un téléphone de milieu de gamme sur un réseau ordinaire. Sur ce site même, un effet de flou appliqué à un fond dégradé faisait retravailler le navigateur à chaque image sur iPhone, pour un résultat identique à l'écran. Le retirer n'a rien changé au rendu et a rendu le défilement fluide. Ce genre de correction ne sort pas d'un rapport automatique, il sort du fait de regarder la page sur un vrai appareil.

L'indexation réserve le même genre de surprises. Sur mon propre blog, des articles publiés ont répondu introuvable pendant un temps parce qu'une étape de publication ne se déclenchait pas dans un cas précis. Le site marchait, les articles existaient, et le robot recevait une erreur. Personne ne l'aurait vu sans aller vérifier ce que le serveur répond vraiment, adresse par adresse. C'est une des premières choses que je regarde sur un site existant, avant même de parler de design.

Il arrive que la bonne réponse ne soit pas une refonte du tout, et c'est le second mandat que couvre cette page. Quelqu'un a une base de code entre les mains et doit décider quoi en faire : un associé s'en va, un développeur part, un investissement se prépare, un projet racheté arrive sans documentation. La question n'est pas de savoir si le code est beau. Elle est de savoir combien il coûtera à faire vivre l'an prochain, et si quelqu'un d'autre peut le reprendre.

Pour y répondre, je fais tourner le projet, je lis le code, et je regarde des choses précises : est-ce qu'il démarre à partir du dépôt seul, est-ce que les bibliothèques sont encore maintenues, est-ce qu'il existe des tests là où une erreur coûte de l'argent, est-ce que des identifiants traînent en clair dans l'historique, comment les données sont découpées, et ce qui se passe quand un service extérieur tombe. Je rends un document écrit : ce qui est solide, ce qui est risqué, ce qui est urgent, et l'ordre dans lequel traiter le reste. Chaque constat renvoie à un endroit précis du code, jamais à une généralité.

Le même travail existe en plus court, avant qu'une seule ligne soit écrite. Faut-il coder cette partie ou prendre un outil existant. Faut-il une application mobile ou le navigateur suffit-il. Ce choix de base de données va-t-il tenir dans deux ans. Ce sont des décisions qui engagent longtemps et qui se prennent souvent en vingt minutes, faute d'avoir quelqu'un à qui les poser. Une discussion honnête à ce moment-là vaut plus cher que trois mois de correction ensuite.

Dans tous les cas, la fin du mandat se ressemble : vous devez pouvoir continuer sans moi. Le dépôt est à votre nom, les décisions sont écrites quelque part, et les mesures de départ existent noir sur blanc pour que la prochaine personne sache d'où elle part.

Ce que j'ai construit

Des applications en ligne, que vous pouvez ouvrir et juger vous-même. J'ai écrit le code de chacune, du premier écran à la mise en production.

Le reste est sur la page des réalisations.

J'écris aussi sur la façon dont ces applications sont faites :

Questions fréquentes

Combien coûte une refonte de site web ?
L'écart entre deux refontes est plus grand qu'entre deux sites neufs, parce que le prix dépend surtout de l'état de ce qui existe. Reprendre une base saine et refaire la façade n'a rien à voir avec récupérer des données coincées dans un système que plus personne ne maintient. Je chiffre après avoir mis les mains dans le projet existant, jamais sur description.
Est-ce que je vais perdre mon référencement ?
C'est le risque principal d'une refonte, et il vient presque toujours de la même erreur : changer les adresses sans les rediriger. L'inventaire des adresses et le plan de redirection s'écrivent donc avant le développement. Après la bascule, je surveille les pages introuvables pendant plusieurs jours, parce que les liens oubliés se révèlent en trafic réel et jamais dans un tableur.
Faut-il tout refaire ou peut-on corriger l'existant ?
Ça dépend de trois choses : est-ce que le projet démarre, est-ce que le code se lit, est-ce que les données sortent. Si les trois réponses sont oui, corriger coûte moins cher et se livre plus vite. Si le projet ne démarre même pas sur ma machine, reconstruire est souvent moins risqué que déterrer. Je réponds après avoir essayé, pas avant.
Combien de temps prend une refonte ?
Un site de présentation remis à neuf se compte en semaines, une application en mois. Comme pour un projet neuf, ce qui allonge les délais n'est pas le code : c'est le contenu à récupérer, les accès à obtenir et les décisions à prendre de votre côté.
Est-ce que mon site reste en ligne pendant les travaux ?
Oui. La refonte se construit à côté, sur une adresse de préproduction, et l'ancien site continue de servir jusqu'à la bascule. Vos visiteurs ne voient rien avant que ce soit prêt, et le retour en arrière reste possible tant que la bascule n'est pas confirmée.
Est-ce que vous travaillez avec WordPress ?
Je n'y construis pas de nouveaux sites, et je préfère le dire franchement. En refonte, c'est un cas fréquent : le site existant est sous WordPress, il faut en sortir le contenu, les adresses et les données, puis les remettre sur une base que je peux tenir. Récupérer ce qui est dedans, oui. Empiler une extension de plus, non.
Est-ce que vous faites seulement la revue de code, sans refonte ?
Oui, et c'est un mandat courant : quelqu'un veut savoir ce que vaut une base de code avant d'investir, d'embaucher ou de reprendre un projet laissé en plan. Je fais tourner le projet, je le lis, et je rends un écrit avec ce qui est solide, ce qui est risqué et ce que coûterait chaque correction. Si le verdict est que le code tient, il tient, et le mandat s'arrête là.
Comment savoir si mon site a vraiment un problème ?
Trois vérifications que vous pouvez faire vous-même avant de m'appeler. Ouvrez votre site sur votre téléphone en données mobiles et comptez les secondes. Cherchez sur Google le titre exact d'une de vos pages intérieures pour voir si elle est indexée. Envoyez-vous une demande par votre propre formulaire et vérifiez qu'elle arrive quelque part. Si l'un des trois échoue, il y a matière à discuter.

Voir aussi : Application web sur mesure, Intégration de systèmes. Tous mes services.

Parlons de ce que vous voulez construire

Le premier appel sert à savoir si le sur-mesure est la bonne réponse à votre problème. Si ce n'en est pas une, je le dis, et vous aurez perdu une demi-heure plutôt qu'un budget.

tokamdarius@gmail.com