Le 16 juin 2026, juste après la mise en ligne du nouveau site Dawap, nous avons traité la refonte comme un vrai chantier de Performance & SEO technique. Le site venait de changer de dimension : nouveaux univers, pages secteurs, produits, formations, blog, projets, preuves commerciales et contenus longs. La question n’était donc pas seulement de publier un beau site, mais de vérifier qu’il restait rapide, propre, indexable et fiable à grande échelle.
Cette fiche complète le projet de refonte du site Dawap. La refonte raconte la reconstruction du positionnement et de l’architecture publique. Ici, nous entrons dans le travail moins visible mais décisif : scores Lighthouse, rendu mobile, HTML, directives d’indexation, médias critiques, accessibilité, bonnes pratiques, maillage interne, sitemap et contrôle de régression.
L’intérêt d’un tel chantier est très concret pour une entreprise qui refond son site. Une refonte peut améliorer l’image tout en abîmant la performance, perdre des signaux SEO, déplacer des contenus importants, charger trop de scripts ou fragiliser les pages mobiles. Nous avons donc construit une méthode pour mesurer, corriger, comparer, puis stabiliser le site avant de continuer la croissance éditoriale.
1. Présentation du client
Dawap comme terrain d’exigence technique, SEO et éditoriale
Dawap accompagne des entreprises sur des sujets où la qualité technique du site public doit inspirer confiance dès les premières secondes : intégration API, marketplace, développement web, IA, produits métier, formation, performance et SEO technique.
Le nouveau site devait donc porter davantage de pages, davantage de contenus et davantage de preuves sans devenir lourd, instable ou difficile à maintenir. Cette contrainte est typique d’un site B2B ambitieux : la richesse éditoriale doit renforcer la confiance sans pénaliser la vitesse, l’indexation ou la lisibilité mobile.
Le client du projet est Dawap lui-même, mais le chantier a été mené comme pour un client externe : analyse de l’existant, priorisation des risques, suivi des tickets, vérifications sur environnement dédié, corrections itératives et validation de la qualité avant de considérer la refonte comme réellement terminée.
2. Méthode projet Dawap
Audit local en production, backlog priorisé et corrections par lots
La première étape a consisté à isoler une mesure fiable. Les scores de performance ne veulent pas dire grand-chose si l’on mesure un Symfony en mode développement, avec barre de debug, assets non représentatifs ou comportements locaux parasites. Nous avons donc préparé un environnement local en mode production, connecté à la base de développement, pour approcher le comportement public sans prendre de risque sur les données.
Le delivery a été piloté en lots courts, avec une logique de backlog comparable à Jira : chaque écart remonté par Lighthouse, le rendu HTML, les captures ou les contrôles route par route devenait un ticket actionnable. Les sujets les plus transverses ont été priorisés en premier : médias critiques, erreurs de console, métas, robots, accessibilité, gabarits partagés et composants réutilisés par plusieurs familles de pages.
La qualité a ensuite été sécurisée par des contrôles de non-régression : audits mobile et desktop, navigation sur les routes critiques, vérification du HTML rendu, lint Twig, validation des nouvelles routes, mise à jour du sitemap et relecture des liens entre les pages de service, projets et contenus longs.
3. Avant le chantier
Une refonte riche peut créer beaucoup de risques invisibles
La refonte du site Dawap avait fortement enrichi le périmètre public : pages d’expertise, pages secteurs, produits, formations, projets, blog, pages légales, pages agence et ressources longues. Ce volume est une force commerciale, mais il multiplie aussi les points de fragilité technique.
Les risques classiques d’une refonte étaient tous présents : images trop lourdes, vidéos qui pèsent sur le mobile, scripts inutiles, liens internes oubliés, métas incohérentes, directives robots difficiles à relire, headings mal hiérarchisés, CLS provoqué par des médias sans dimensions, routes nouvelles absentes du sitemap ou composants communs qui dégradent des dizaines de pages à la fois.
Le coût métier d’un tel risque est clair : une page lente convertit moins, un HTML confus se maintient moins bien, un contenu mal relié se découvre moins facilement, et une refonte qui perd en SEO technique oblige ensuite les équipes à réparer dans l’urgence ce qui aurait dû être sécurisé au moment de la mise en ligne.
4. Objectifs techniques
Viser un site rapide, propre, indexable et stable
Le premier objectif était d’obtenir un socle de mesure fiable, proche de la production, pour arrêter de comparer des scores influencés par l’environnement de développement. Les audits devaient être lancés dans un contexte Symfony propre, avec assets compilés, cache chaud et sans outils de debug visibles dans le rendu.
Le deuxième objectif était de pousser au maximum les scores hors performance pure : bonnes pratiques, accessibilité et SEO devaient atteindre 100 lorsque les contraintes de contenu le permettaient. Les baisses résiduelles devaient être compréhensibles, documentées et traitées par ordre d’impact.
Le troisième objectif portait sur la performance. Nous voulions améliorer les points faciles et transverses en premier : images, vidéos, poster mobile, dimensions explicites, chargement différé, préchargement des médias critiques, suppression des erreurs de console et réduction des éléments qui bloquent le rendu initial.
5. Environnement de mesure
Faire tourner le site localement en mode production
Un point important du chantier a été de séparer la donnée, le code et le mode d’exécution. Le site pouvait continuer à pointer vers la base de développement, mais Symfony devait tourner en mode production local pour reproduire un rendu plus proche du public : cache, compilation, absence de barre de debug et ressources front plus représentatives.
Ce choix a permis de lancer des audits sans toucher à la production réelle. Les pages restaient accessibles localement, mais elles étaient mesurées dans des conditions plus sérieuses que le mode développement. C’est une approche utile lorsqu’une équipe veut améliorer PageSpeed, Lighthouse ou GTmetrix avant une bascule publique.
Nous avons aussi vérifié les directives d’indexation directement dans le HTML rendu. En local et en sandbox, certains cas peuvent volontairement rester indexables pour permettre des tests. En production publique, la décision doit être portée par les métas, les canoniques et les règles attendues par les moteurs, pas par une hypothèse invisible.
6. Audit à grande échelle
Ne pas valider seulement une page qui passe bien
La première page testée, Agence marketplace vendeurs, a servi de page de référence parce qu’elle combinait vidéo, image, textes longs, logos, CTA, tags, sections d’offre et composants partagés. C’était un bon candidat pour trouver rapidement les irritants visibles.
Ensuite, la démarche a été étendue au site. Les contrôles ont couvert 1 890 URLs, avec un passage mobile et un passage desktop, soit 3 780 mesures Lighthouse. L’objectif n’était pas de regarder une moyenne flatteuse, mais d’identifier les familles de pages qui faisaient baisser la qualité globale.
Cette approche par volume change le type de décisions. Une anomalie présente sur une seule page devient un correctif local. Une anomalie présente sur un gabarit, un composant, une image commune ou une règle de rendu devient prioritaire, parce qu’elle peut améliorer des dizaines ou des centaines de pages en une seule correction.
7. Performance et médias
Garder l’impact visuel sans pénaliser le rendu initial
Le travail le plus visible a porté sur les médias du haut de page. La vidéo apporte une identité forte sur desktop, mais elle ne doit pas devenir un poids inutile sur mobile. Le comportement a donc été revu pour conserver l’impact sur grand écran et s’appuyer sur une image de couverture optimisée lorsque le contexte mobile le justifie.
Les images critiques ont été traitées avec plus de rigueur : dimensions explicites, formats adaptés, chargement différé lorsque le média n’est pas prioritaire, préchargement des éléments réellement utiles au rendu initial et réduction des surprises de layout. Ce sont des détails très concrets, mais ils pèsent directement sur LCP, CLS et vitesse perçue.
La page Agence marketplace a aussi permis de corriger un point de rendu immédiatement visible : l’optimisation ne devait pas déformer le hero, réduire sa largeur ou ajouter un arrondi parasite autour de la vidéo. Une optimisation n’est acceptable que si elle améliore les scores sans casser la direction graphique.
8. HTML et accessibilité
Rendre les pages compréhensibles pour les humains, les outils et les moteurs
La passe qualité a vérifié le HTML rendu, pas seulement les templates. C’est important : un Twig peut sembler propre, mais le navigateur, Lighthouse ou un robot ne voient que le résultat final. Les contrôles ont donc porté sur la hiérarchie des titres, les liens, les textes alternatifs, les noms accessibles, les contrastes, les labels, les boutons et les éléments interactifs.
Les corrections d’accessibilité ont été abordées comme des corrections de produit. Un bouton sans nom, une image décorative mal décrite ou une structure de titre incohérente ne sont pas seulement des points Lighthouse : ce sont des obstacles pour des lecteurs, des outils d’assistance, des crawlers et des équipes qui maintiendront la page demain.
L’objectif était d’obtenir un socle à 100 sur l’accessibilité lorsqu’aucune contrainte réelle ne l’empêche, puis de garder ce niveau sur les gabarits partagés. C’est plus rentable que de corriger page par page une erreur reproduite partout.
9. Indexation, métas et directives robots
Porter les décisions SEO dans le HTML, là où elles sont vérifiables
Une discussion importante du chantier a porté sur l’indexation. La question n’était pas seulement de savoir si un environnement local devait être index ou noindex. Le vrai sujet était de savoir où la décision est visible et contrôlable : dans le HTML, via les métas, les canoniques et les directives que les moteurs comprennent réellement.
Nous avons donc vérifié les pages publiques en nous concentrant sur le rendu final : title, description, canonical, Open Graph, robots, liens internes, sitemap et cohérence entre route, contenu et intention. Pour un site qui publie beaucoup de pages, cette discipline évite les contradictions entre configuration serveur, template et stratégie SEO.
Le nouveau projet a aussi déclenché la mise à jour du sitemap. Toute page publique ajoutée ou modifiée doit avoir une entrée cohérente, avec route, fréquence, priorité et `lastmod`. C’est une règle simple, mais elle évite de publier des contenus importants sans signal de fraîcheur propre.
10. Maillage interne
Relier la preuve, l’offre et les pages utiles sans bruit
Le maillage interne a été pensé pour aider le lecteur à passer de la preuve au service. Cette fiche renvoie naturellement vers la refonte du site Dawap, parce que les deux projets racontent le même chantier sous deux angles complémentaires : architecture et positionnement d’un côté, qualité technique et SEO de l’autre.
Les quatre pages de service Tech SEO sont également reliées au récit : Audit Tech SEO complet, Optimisation technique SEO, Performance & Core Web Vitals et Sécurité & accessibilité.
Ce maillage n’a pas été ajouté pour remplir la page. Il correspond au vrai déroulé du chantier : analyser, corriger les gabarits, améliorer les signaux de performance, renforcer l’accessibilité et sécuriser la qualité technique avant de poursuivre la croissance éditoriale.
11. Qualité et non-régression
Transformer les audits en corrections qui tiennent
Chaque correction a été relue sous deux angles : le score et le rendu. Un score qui monte mais dégrade le design n’est pas une victoire. Un rendu parfait qui cache une erreur Lighthouse massive n’est pas suffisant non plus. Le bon résultat est celui qui tient les deux exigences en même temps.
Les contrôles ont porté sur les routes critiques, les pages de service, les projets, les ressources longues, les composants communs, les médias et le sitemap. Les fichiers Twig modifiés ont été relus, les nouvelles routes validées, et les changements de rendu public ont été accompagnés des mises à jour SEO opérationnelles nécessaires.
Cette étape de non-régression est essentielle sur un site riche. Quand une équipe corrige un hero, un composant de carte ou un bloc de navigation, elle peut améliorer une page et en casser vingt autres. L’audit large sert justement à éviter ce type d’effet secondaire.
12. Résultats mesurés
Des scores stabilisés, avec les écarts de performance isolés
Sur l’environnement local en mode production, l’audit global a couvert 1 890 URLs en mobile et desktop. Les scores moyens obtenus étaient très élevés : 99,99 en desktop, 97,06 en mobile, et 100 sur accessibilité, bonnes pratiques et SEO lorsque les pages étaient agrégées par familles.
Les pages blog ont notamment atteint une moyenne desktop de 100 et une moyenne mobile de 96,84. Les écarts restants étaient principalement liés à la performance mobile, ce qui correspond au comportement attendu d’un site riche en contenus, visuels et composants lorsque l’on mesure avec un profil mobile contraint.
Le plus important n’est pas seulement la moyenne. Le chantier a permis d’identifier les causes récurrentes, de corriger les irritants visibles, de stabiliser le rendu de la page Agence marketplace, de fiabiliser les métas, et de confirmer que les scores accessibilité, bonnes pratiques et SEO pouvaient être portés au maximum sur le socle.
13. Ce que cela change pour un client
Une refonte mieux sécurisée, plus mesurable et plus durable
Pour une entreprise qui prépare une refonte, cette méthode réduit un risque très fréquent : découvrir les problèmes après la mise en production, quand les pages sont déjà crawlées, partagées, indexées et utilisées par les équipes commerciales. Le contrôle en amont permet de corriger avant que le problème ne devienne public.
Le client gagne aussi une meilleure capacité de décision. Au lieu d’une liste abstraite de recommandations, il obtient une hiérarchie claire : ce qui bloque les scores, ce qui abîme le rendu, ce qui touche beaucoup de pages, ce qui peut attendre, et ce qui doit être traité avant la publication.
Enfin, le site devient plus durable. Les pages peuvent continuer à évoluer, les nouveaux contenus peuvent s’insérer dans une structure propre, et les équipes disposent d’un socle plus fiable pour suivre la performance, l’indexation, l’accessibilité et la qualité de rendu dans le temps.
14. Conclusion
Une refonte n’est vraiment terminée que lorsque le socle tient
Ce projet montre pourquoi le SEO technique doit accompagner une refonte jusqu’au bout. Le risque n’est pas seulement de perdre quelques points Lighthouse : c’est de publier un site plus riche mais plus fragile, plus lent, moins lisible sur mobile ou moins clair pour les moteurs de recherche.
La valeur créée tient dans la discipline : mesurer dans un environnement représentatif, corriger les causes partagées avant les détails isolés, vérifier les métas dans le HTML, maintenir l’indexation au bon endroit, garder les médias sous contrôle et relier les pages entre elles avec une logique utile pour le lecteur.
Pour une entreprise qui prépare une refonte, c’est exactement le type d’accompagnement que Dawap apporte avec son expertise Performance & SEO technique : transformer les audits en corrections livrées, testées et maintenables.
