Le projet en un coup d’œil
Le nouveau site devait organiser plusieurs expertises, rendre leurs pages explorables et reprendre les URLs de deux générations antérieures sans confondre volume publié et visibilité acquise.
Symfony porte des routes et gabarits explicites ; une commande construit le sitemap, tandis que Nginx conserve les redirections et le cache long des ressources statiques.
Entre juillet et novembre 2023, le site ajoute ses univers, ses preuves, son maillage, 205 médias WebP, 100 redirections et une première reprise du chargement mobile.
En 2023, Dawap reconstruit son site autour d’une offre plus large que quelques pages institutionnelles. Création de marketplace, développement et automatisation par API, solutions web sur mesure, performance et SEO technique doivent former des parcours séparés mais reliés. Chaque nouvelle page crée une route, une métadonnée, une place dans le maillage et une responsabilité de migration.
La première séquence démarre le 27 juillet avec les pages de services, l’espace projets et quatre visuels d’en-tête convertis en WebP. Le lendemain, l’univers performance et SEO détaille audit, vitesse, mobile, monitoring, cache, e-commerce, blog et balises. Le produit pose ses catégories commerciales avant de traiter leur découvrabilité à l’échelle.
Octobre transforme ce catalogue en socle SEO exploitable. Une première commande de sitemap déclare 45 URLs le 5 octobre, puis 59 trois jours plus tard et 129 au 26 novembre. Les redirections permanentes passent de treize règles à quatre-vingt-dix, puis cent. Menus, ancres et navigations contextuelles relient parallèlement les branches de l’offre.
Le dernier jalon retenu, le 26 novembre 2023, déplace plusieurs feuilles de style après le chargement du document et ajuste les scripts du layout pour travailler la restitution mobile. Cette histoire précède la refonte complète de Dawap.fr en 2026 et son contrôle technique de 1 890 URLs.
1. Un site d’agence devenu catalogue d’expertises et de preuves
Rendre lisible une offre qui croise marketplace, API, web sur mesure et SEO
Dawap devait présenter plusieurs métiers qui coopèrent sur les mêmes projets. Une marketplace mobilise souvent frontend, APIs, données catalogue, performance et SEO. Un menu par technologie aurait mal raconté ces relations ; un menu trop dense aurait rendu l’offre illisible. Le site choisit des univers, des sous-pages de besoins et des fiches projet reliées.
Cette profondeur sert deux lecteurs. Une entreprise peut partir d’un problème — choisir un moteur, intégrer une API, développer une application ou améliorer une page — puis progresser vers une méthode et une réalisation concrète. Le moteur reçoit des pages aux routes, titres et descriptions propres. Le même découpage doit rester cohérent dans la navigation, le sitemap et les redirections.
Le socle livré en novembre 2023 repose sur Symfony 5.2 et Twig. Les contrôleurs déclarent les pages, les gabarits portent le contenu et le générateur de sitemap énumère les routes publiques. Nginx prend en charge le domaine sans www, les anciennes adresses et la durée de cache des fichiers statiques.
Le projet est une réalisation interne : aucun témoignage client n’est nécessaire et aucune validation fictive n’est ajoutée. Il expose aussi ses limites : couverture canonical faible, sitemap non atomique, CI sans test automatisé et mesures organiques absentes pour cette période.
2. Cent vingt-trois jours pour relier contenu, exploration et migration
Du 27 juillet au 26 novembre 2023, sans assimiler la fenêtre à une charge continue
Juillet pose les quatre grandes branches, les pages projets et les premiers médias optimisés. Chaque service reçoit progressivement son contrôleur et son gabarit. Cette phase crée la matière du site ; elle ne prouve pas encore que toutes les pages sont correctement reliées, migrées ou mesurées.
Début octobre, l’architecture marketplace est reprise. Le sitemap apparaît avec une liste de routes, une priorité et une fréquence. Les premières redirections 301 préparent le changement d’adresses. Les fiches produit et projet rejoignent ensuite l’inventaire public.
La seconde moitié d’octobre travaille les passages entre pages. Des navigations secondaires apparaissent, les ancres sont corrigées et le maillage marketplace s’étoffe. Les univers API et SEO sont enrichis en parallèle. La configuration de production récupère les règles de redirection préparées en pipeline.
Novembre apporte des corrections de 404, des ajustements de médias et une intervention sur le coût du layout mobile. Les 123 jours décrivent la période entre le premier socle et ce dernier jalon, pas des jours facturés ni une méthode de sprint.
3. Distinguer le socle 2023 de l’audit de refonte 2026
Deux étapes du même site, deux preuves et deux niveaux de mesure
Le périmètre 2023 réunit routes, gabarits, sitemap, redirections, maillage, images et layout jusqu’au 26 novembre. La refonte menée en 2026 constitue une étape distincte, avec une architecture et un protocole de mesure propres.
La refonte 2026 contrôle 1 890 URLs après une transformation profonde, contre 129 déclarées dans le sitemap du socle 2023. Ces nombres ne sont pas directement comparables : arborescence, contenus, pile technique et protocole ont changé.
Le travail porte sur le propre site de l’agence : construire les pages, organiser leur découverte, préparer les migrations et contrôler le produit obtenu. Il ne s’agit pas d’un rapport autonome détaché de la réalisation.
Les capacités livrées suffisent à rendre la transformation lisible : une offre structurée, une surface publique inventoriée, des anciennes adresses reprises et un socle que les évolutions suivantes peuvent mesurer puis renforcer.
4. Transformer quatre expertises en architecture de navigation
Des branches distinctes, reliées par les problèmes des entreprises
Le site s’ouvre sur quatre axes : marketplace, développement et automatisation par API, solution web sur mesure, performance et SEO technique. Chaque branche reçoit une page d’entrée puis des sous-pages plus précises. Agence, produits et projets complètent cette lecture par la méthode et la preuve.
Une page générale présente la proposition de valeur ; une sous-page traite une intention étroite ; une fiche projet montre comment plusieurs expertises se rejoignent. Le lecteur n’est pas obligé de connaître la technologie avant de commencer son parcours.
Dans le sitemap final, vingt-neuf routes appartiennent à la marketplace, trente et une à l’API, douze à la performance SEO, onze aux produits et vingt-huit aux projets. Les autres couvrent agence, applications métier, accueil, services et contact. Ces comptes ne disent rien de leur trafic ou indexation.
Créer une route reste plus facile que lui donner une intention distincte. Le projet limite une partie du risque par des navigations dédiées. La gouvernance éditoriale doit ensuite vérifier que chaque page apporte une réponse propre au lieu de répéter sa page mère.
5. Donner un titre et une description à cent trente-deux gabarits
Une couverture éditoriale large, mais une canonical marginale
Au jalon de novembre, cent trente-deux fichiers Twig déclarent à la fois un bloc de titre et un bloc de description. Le layout centralise leur emplacement dans le head, puis chaque page fournit son texte. Cette structure différencie les entrées du catalogue sans registre séparé.
Les métadonnées restent proches du contenu qui les explique. Lorsqu’une page change de positionnement, titre, description, H1 et liens peuvent évoluer ensemble. Cette proximité limite certains oublis, mais n’empêche ni duplication ni longueur inadaptée.
La canonical est moins couverte : seuls deux fichiers Twig déclarent ou spécialisent le bloc dans cette version. Le layout prévoit l’emplacement, mais la majorité des pages ne fournit pas d’URL de référence. Le socle de métadonnées est réel sans être complet.
La garantie suivante doit tester le HTML rendu. Une matrice peut contrôler unicité du title, description non vide, H1 unique, canonical absolue, directives robots et cohérence entre route et fil d’Ariane pour chaque famille.
6. Faire évoluer le sitemap de 45 à 129 URLs explicites
Choisir la surface publiée plutôt qu’exporter tout le routeur
Le 5 octobre 2023, la première commande assemble quarante-cinq URLs. Trois jours plus tard, produits et premiers projets portent l’inventaire à cinquante-neuf. Les enrichissements d’octobre et novembre conduisent aux cent vingt-neuf entrées de référence.
Chaque entrée associe route Symfony, fréquence, priorité et date. La commande construit les URLs avec le domaine configuré, écrit un fragment puis un index. Une limite de mille URLs par fichier prépare un volume supérieur, même si les 129 entrées tiennent dans un seul fragment.
L’énumération explicite exclut les routes internes ou non finalisées. L’équipe choisit ce qu’elle publie. Son coût est manuel : toute nouvelle page doit être ajoutée et toute ancienne route retirée, sinon l’inventaire diverge du site.
Toutes les pages reçoivent cependant la date du jour à chaque exécution, même sans changement. Le dossier existant est vidé avant la création des nouveaux fichiers. Le système génère un sitemap, mais ne préserve ni un lastmod éditorial ni une publication atomique.
7. Construire cent redirections permanentes pour trois générations de site
Préserver les chemins sans faire de l’accueil une destination universelle
Les premières règles apparaissent le 8 octobre avec treize redirections 301. Le 27 octobre, les configurations de pipeline et production en comptent quatre-vingt-dix. Dix règles supplémentaires portent l’ensemble à cent. Le domaine www est également redirigé vers le domaine nu.
Les sources couvrent anciennes pages d’agence, marketplace, API, solutions web, projets et articles. Certaines vont vers un équivalent précis : une ancienne page d’audit rejoint l’offre d’audit, une page frontend rejoint la nouvelle branche frontend et plusieurs projets conservent leur fiche.
D’autres règles renvoient vers une page mère, les projets ou l’accueil. Ce choix évite une erreur immédiate mais ne conserve pas toujours l’intention. Un ancien article envoyé vers l’accueil peut être moins utile qu’une réponse 410 assumée si aucun remplacement n’existe.
Nginx rend la migration versionnable avec le site. Un dispositif complet exige aussi inventaire source-destination, contrôle des chaînes et boucles, test de statut et suivi des anciennes URLs encore explorées.
8. Relier les pages par besoin plutôt que par simple proximité
Faire circuler le lecteur entre offre, sous-problème et preuve
Fin octobre, plusieurs pages marketplace reçoivent des navigations internes plus denses. Analyse, choix du moteur, frontend, automatisation, performance, SEO, statistiques et outils se renvoient selon le sujet. Des correctifs reprennent aussi des ancres incorrectes.
Une navigation SEO marketplace relie audit, monitoring, accessibilité, performance, optimisation et bonnes pratiques. La logique se développe sur les pages API et performance. Le maillage ne dépend plus seulement du menu principal : il accompagne le contenu.
Un lecteur parti d’un problème de performance peut comprendre qu’il touche aussi le frontend et le SEO ; une personne qui lit une preuve peut rejoindre l’expertise. Ces liens contextualisent mieux les offres qu’une liste identique répétée partout.
Aucun relevé ne mesure profondeur moyenne, pages orphelines ou clics sur ces liens en 2023. La capacité existe, mais son efficacité doit être contrôlée par crawl et analytique. Le projet ne transforme pas le maillage construit en gain de trafic déclaré.
9. Mettre 205 médias WebP à disposition des pages
Réduire le poids potentiel sans inventer un gain mesuré
Dès le 27 juillet, quatre visuels d’en-tête sont ajoutés en WebP pour les grandes branches. Leurs fichiers pèsent environ 111 à 166 Ko. Les enrichissements suivants généralisent le format aux services, produits, projets et illustrations.
La version du 26 novembre contient 205 WebP dans le répertoire public. Plusieurs images gardent aussi un PNG. Les gabarits emploient régulièrement loading="lazy", dimensions et texte alternatif, avec une qualité variable selon les pages.
Format moderne et chargement différé sont des leviers réels. Ils réduisent le risque de charger un PNG plus lourd ou un média hors écran dès l’ouverture. Ils ne prouvent pas seuls une baisse du LCP, du poids ou du rebond : aucune comparaison n’est conservée.
Une chaîne plus mature produirait plusieurs largeurs, déclarerait srcset et sizes, fixerait le ratio, mesurerait les poids et bloquerait les régressions au build. Le WebP deviendrait une politique de média plutôt qu’un stock d’alternatives.
10. Reprendre le chargement mobile dans le layout partagé
Une seule modification peut toucher toutes les pages
Le 26 novembre, le layout retire trois feuilles de style du chargement direct. Swiper et les icônes sont ajoutés après DOMContentLoaded, tandis que la feuille principale reste dans le head. Plusieurs scripts conservent ou reçoivent des attributs asynchrones et différés.
Corriger le layout agit sur toutes les pages sans modifier chaque gabarit. L’intervention cible le chemin critique mobile, où des ressources secondaires peuvent retarder l’affichage. L’impact potentiel est large parce que la cause est commune.
Le choix comporte un arbitrage. Une feuille chargée après le document peut afficher tardivement icônes ou composants ; le script AOS n’est plus différé dans la version finale. Sans mesure de laboratoire ni terrain, annoncer une amélioration nette serait trompeur.
La suite est un budget par layout : CSS critique, JavaScript initial, polices, image principale, requêtes et seuils Lighthouse. Un test visuel doit repérer un flash sans style ou une interaction disponible trop tard.
11. Servir les ressources statiques avec un cache d’un an
Un levier qui exige des noms de fichiers stables
La production applique une expiration de 365 jours aux images, CSS, scripts, vidéos, icônes et polices. Un visiteur régulier peut réutiliser les ressources téléchargées au lieu de solliciter le serveur à chaque page.
Cette durée est cohérente lorsque l’URL change avec le contenu. Elle devient risquée si style.min.css est remplacé sous le même nom : le navigateur peut conserver l’ancienne version. La configuration ne prouve pas un fingerprint systématique de tous les actifs.
Le cache long doit donc être relié au build. Les ressources immuables reçoivent un hash et une directive forte ; les fichiers non versionnés gardent une durée prudente ou une revalidation. Cette distinction évite d’opposer performance et capacité de correction.
Aucun taux de cache ni temps de réponse n’est conservé. Le gain démontrable est la règle d’expiration. Son effet dépend des en-têtes finaux, du CDN éventuel, des noms de fichiers et des comportements de visite.
12. Construire et publier les images applicatives sans tests automatisés
Une chaîne de livraison présente, mais une validation incomplète
La CI distingue develop et main. Elle construit des images PHP et Nginx, les pousse au registre puis retague l’image PHP destinée à la livraison. Les Dockerfiles séparent les contextes de pipeline et production.
La chaîne ne contient que les étapes build et push. Aucun job ne lance PHPUnit, lint Twig, crawl, test de sitemap ou contrôle de redirections. Le nom d’une image « testée » ne remplace pas l’exécution d’une suite.
PHPUnit est déclaré en dépendance de développement. Les routes, gabarits et configurations constituent les premiers invariants à protéger par des tests de non-régression.
Cette limite compte pour le SEO : une faute de route casse le sitemap, une balise vide touche une famille et une règle Nginx mal ordonnée change une destination. Les contrôles doivent précéder le push, puis être rejoués sur l’environnement déployé.
13. Suivre une ancienne URL jusqu’à une page utile et explorable
La migration est complète lorsque le parcours conserve son sens
Prenons une ancienne page de développement frontend marketplace. Nginx la reconnaît exactement et répond en 301 vers la nouvelle page frontend. Le navigateur et le moteur n’arrivent ni sur une erreur ni sur un chemin sans rapport.
La destination fournit titre, description et H1 dans son gabarit. Son contenu renvoie vers les autres étapes de création de marketplace et vers des preuves. La page figure dans le sitemap. Redirection, contenu, maillage et exploration décrivent une même intention.
La destination doit néanmoins répondre en 200, éviter une seconde redirection, déclarer une canonical cohérente, rester accessible sans JavaScript et conserver ses ressources critiques. Un changement de slug doit mettre à jour Nginx, sitemap et liens ensemble.
Le site 2023 possède les briques, mais pas ce test bout en bout. L’audit Tech SEO et le monitoring de non-régression sont les prolongements naturels.
14. Formuler les gains réellement observables
Une surface inventoriée, une migration versionnée et des parcours reliés
Pour l’éditorial, les familles disposent de pages et métadonnées dédiées. Un contenu s’inscrit dans une branche connue plutôt que créer une adresse sans parent. Le sitemap fournit un inventaire relisible des routes choisies.
Pour la technique, les redirections vivent avec la production, le layout centralise les ressources et le build produit les images applicatives. Une correction commune peut couvrir toutes les pages ; une ancienne adresse peut recevoir une destination explicite.
Pour le visiteur, les expertises deviennent des parcours plutôt qu’une liste de mots-clés. Les liens permettent de passer d’un problème à une sous-page puis à une preuve. WebP et cache long réduisent le coût potentiel des visites successives.
Pour les moteurs, 129 URLs sont déclarées, les migrations majeures utilisent des 301 et 132 gabarits portent titre et description. Ces capacités rendent le site contrôlable et donnent une base mesurable pour suivre l’indexation, les requêtes et les prises de contact.
15. Rendre visibles les faiblesses du premier socle
Le nombre de mécanismes ne remplace pas leur contrôle
Première faiblesse : deux fichiers canoniques pour 132 gabarits dotés de métadonnées. Deuxième : les dates du sitemap recalculées à chaque génération. Troisième : les anciens fragments supprimés avant l’écriture des nouveaux.
La commande retourne true alors qu’une commande Symfony attend un code de succès égal à zéro. Ce détail peut signaler un échec malgré la génération. La limite de mille URLs doit aussi être testée lorsque le second fragment apparaît.
Les cent redirections mélangent correspondances précises et replis généraux. Leur nombre est une preuve de travail, pas un score de qualité. Chaque destination doit être justifiée par l’intention et suivie tant que l’ancienne URL reçoit visites ou crawls.
Enfin, la performance mobile reste à instrumenter : les 205 WebP n’ont pas encore de budget global et la CI ne teste pas le HTML public. Ces limites définissent un socle utile, avec des garanties précises à ajouter lors de l’étape suivante.
16. Transformer le socle en contrat SEO automatisé
Inventorier, rendre, tester, mesurer puis surveiller
Un registre unique doit associer URL, page propriétaire, intention, canonical, indexabilité, sitemap et ancienne adresse éventuelle. Le sitemap et les tests de redirection peuvent être contrôlés depuis la même source.
Pour chaque famille, un scénario ouvre la page et vérifie statut, title, description, H1, canonical, robots, données structurées, médias critiques et liens majeurs. Les erreurs communes se corrigent dans le layout ; les exceptions restent explicites.
Des budgets sur CSS, JavaScript, images et polices complètent des mesures mobile et desktop. La page Performance et Core Web Vitals distingue laboratoire reproductible et données terrain.
Crawl, anciennes URLs, âge du sitemap, couverture, impressions, clics et conversions doivent être rattachés à une date et une famille. Une alerte devient utile lorsqu’elle conduit à une décision, pas lorsqu’elle transforme chaque variation en urgence.
17. Faire du site 2023 le point de départ, pas la preuve finale
La refonte 2026 reprend les limites avec un protocole plus exigeant
Le site 2023 donne à Dawap une architecture de services, des preuves, un sitemap, des redirections et un cadre de performance. Il révèle aussi les coûts d’une croissance manuelle : inventaires à synchroniser, canoniques incomplètes, migrations hétérogènes et absence de tests publics.
La refonte du site Dawap reprend positionnement, navigation et modèle de contenu. Le projet SEO de la refonte ajoute ensuite 3 780 audits Lighthouse sur 1 890 URLs.
La continuité entre 2023 et 2026 montre comment un site apprend de sa première architecture. Ses garanties progressent avec son volume : les 129 URLs initiales expliquent le besoin d’un contrôle industriel lorsque le périmètre devient beaucoup plus large.
Pour une trajectoire similaire, Dawap relie le développement de site sur mesure, la migration SEO, la performance et la non-régression. Le but est de pouvoir expliquer, tester et mesurer chaque famille publiée.
18. Un socle SEO vaut par ce qu’il rend contrôlable
Routes, métadonnées, redirections et médias doivent raconter la même architecture
La version 2023 ne fournit pas une courbe de trafic à célébrer. Elle prouve qu’une offre complexe peut devenir un ensemble de routes explicites, pages nommées, liens contextuels, redirections et médias modernes. Le sitemap inventorie cette surface au lieu de la laisser implicite.
Elle montre aussi pourquoi le chantier ne s’arrête pas au lancement. Cent redirections préservent des chemins, mais certaines destinations restent trop génériques. Cent vingt-neuf entrées guident l’exploration, mais leur date doit refléter les contenus réels. Deux gabarits canoniques ne suffisent pas pour cent trente-deux pages dotées de métadonnées.
La suite logique est la migration et refonte SEO : construire une matrice d’URLs, rapprocher les intentions, tester les réponses, mesurer le rendu puis surveiller les signaux réels. La campagne Dawap de 2026 prolonge cette trajectoire avec un protocole instrumenté.
