Aller au contenu

Refondre dolist.com de A à Z

Il y a des projets web qui commencent avec une page blanche.

Celui-ci a commencé avec quatre sites.

Quatre sites pour une seule entreprise.
Quatre portes d'entrée.
Quatre manières de présenter des offres qui, dans la réalité, faisaient partie du même écosystème.

D'un côté, il y avait dolist.com, le site principal : la marque, le blog, les ressources, les cas clients, une grosse partie de l'historique SEO.

À côté, il y avait aussi :

  • un site pour Campaign, la plateforme d'activation e-mail et SMS
  • un site pour Welkom Editor, l'email builder
  • un site pour les services Dolist, autour du conseil, du Studio, de la délivrabilité, de la data, des formations.

Sur le papier, chaque site avait sa logique.

Dans la réalité, pour quelqu'un qui découvre Dolist, ça pouvait vite devenir flou.

Où commence la plateforme ?
Où finissent les services ?
Est-ce que l'email builder est un produit séparé ?
Est-ce que le conseil est une offre à part ?
Pourquoi certaines expertises sont sur un domaine, d'autres ailleurs ?
Et surtout : comment tout ça se rassemble dans une proposition claire ?

La refonte de dolist.com n'a donc pas été seulement une refonte graphique.

C'était une reprise complète de l'écosystème web.

Une tentative de remettre de l'ordre dans plusieurs années de contenus, d'offres, d'URLs, d'habitudes, de pages SEO, de ressources et de choix historiques.

Ce que je raconte ici

Ce n'est pas une méthode parfaite de refonte web.
C'est un retour d'expérience sur un projet réel, avec ses arbitrages, ses angles morts, ses contraintes, ses erreurs et ses moments de flottement.

Ce projet a été conduit avec une agence web partenaire, qui a porté la conception graphique, la direction artistique, l'intégration WordPress et la production technique du site. Ce que je raconte ici, c'est surtout mon périmètre : architecture, SEO, contenus, coordination et arbitrages côté Dolist.

En résumé

Refonte complète de dolist.com : consolidation de 4 sites distincts (dolist.com, campaign.dolist.com, email-builder.dolist.com, services.dolist.com) en un seul écosystème web unifié.

Ce que couvre cet article :

  • Pourquoi la fragmentation multi-sites posait problème : SEO, lisibilité, cohérence
  • L'architecture d'information retenue : Plateforme, Services, Enjeux, Ressources
  • Le travail SEO : slugs, titles, metas, redirections 301
  • Le travail de contenu : réécriture, nettoyage HTML, voix éditoriale
  • La recette, les formulaires, le tracking post-lancement
  • Ce qui a été compliqué, ce qui a bien fonctionné, et les leçons retenues

Cahier des charges source

Ce projet a démarré avec un cahier des charges complet. Je le mets à disposition tel quel — certaines données chiffrées ont été retirées, le reste est intact.

Télécharger le cahier des charges (PDF, 956 Ko)

Le vrai problème de départ

Le problème n'était pas uniquement :

"Le site a besoin d'un nouveau design."

C'était plutôt :

"Notre présence web ne reflète plus clairement ce que Dolist est devenu."

Dolist n'est pas juste un éditeur SaaS.
Dolist n'est pas juste un prestataire de services.
Dolist n'est pas juste une plateforme e-mailing.
Dolist n'est pas juste un blog expert sur l'e-mail marketing.

C'est un ensemble plus hybride :

  • une plateforme d'activation e-mail et SMS
  • un email builder collaboratif
  • des services d'accompagnement marketing et technique
  • une expertise délivrabilité
  • des sujets forts autour du RGPD, de la sécurité, de l'accessibilité et du numérique responsable
  • des contenus éditoriaux historiques
  • des ressources très SEO
  • des cas clients
  • des formations
  • une vraie culture métier autour de l'adressage digital.

Le site devait donc faire quelque chose d'assez difficile :

rassembler sans tout aplatir.

Il fallait réunifier l'écosystème, mais sans perdre les spécificités.

Campaign ne devait pas devenir une simple page produit vague.
Welkom Editor ne devait pas disparaître derrière le mot "outil".
Les services ne devaient pas être réduits à une liste d'accompagnements.
Les ressources ne devaient pas devenir une bibliothèque mal rangée.
Et le SEO existant ne devait pas être sacrifié au nom d'une refonte plus propre.

Pourquoi ce projet m'a intéressé

Ce projet m'a intéressé parce qu'il cochait exactement les cases des projets web que je trouve les plus stimulants.

Pas les projets où l'on applique une recette.

Les projets où il faut relier des choses qui ne parlent pas toujours le même langage :

  • le SEO veut préserver l'existant
  • le design veut simplifier
  • le contenu veut expliquer
  • le business veut vendre
  • les équipes internes veulent retrouver leurs offres
  • les utilisateurs veulent comprendre vite
  • le CMS impose ses contraintes
  • les redirections rappellent que chaque URL a une histoire.

Sur ce genre de projet, une décision n'est presque jamais pure.

Changer un slug peut sembler anodin, mais ça touche au SEO, aux redirections, à la lisibilité, aux anciennes campagnes, au maillage interne.

Fusionner deux pages peut sembler logique, mais ça peut faire perdre une nuance importante.

Supprimer une page peut rendre l'arborescence plus propre, mais casser un ancien point d'entrée.

Réécrire un H1 peut améliorer la clarté, mais affaiblir une requête historique.

C'est ce qui rend le projet intéressant.

Une refonte web, quand elle est prise au sérieux, ce n'est pas "faire plus moderne".

C'est arbitrer en permanence entre lisibilité, performance, héritage et projection.

Mon rôle a surtout été de faire le lien entre tout ça : l'existant, les objectifs SEO, les offres, les contenus et ce que le site devait permettre. Avec l'agence, nous avons ensuite construit le site à partir de cette matière. C'est cet espace de pilotage et d'arbitrage que je décris dans cet article.

Le contexte : quatre sites, un seul discours à reconstruire

Avant la refonte, Dolist existait à travers plusieurs sites.

flowchart TD
    A[Écosystème web Dolist avant refonte] --> B[dolist.com]
    A --> C[campaign.dolist.com]
    A --> D[email-builder.dolist.com]
    A --> E[services.dolist.com]

    B --> B1[Marque]
    B --> B2[Blog]
    B --> B3[Ressources]
    B --> B4[Cas clients]
    B --> B5[SEO historique]

    C --> C1[Campaign]
    C --> C2[Plateforme e-mail & SMS]
    C --> C3[Marketing automation]
    C --> C4[Transactionnel]

    D --> D1[Welkom Editor]
    D --> D2[Email builder]
    D --> D3[Responsive]
    D --> D4[Accessibilité]

    E --> E1[Conseil]
    E --> E2[Studio]
    E --> E3[Délivrabilité]
    E --> E4[Dataviz]
    E --> E5[Formations]

Cette dispersion avait une logique historique.

Chaque offre avait probablement eu besoin de son espace, de ses pages, de son discours, de ses formulaires, de son autonomie.

Mais avec le temps, ce découpage créait plusieurs problèmes.

Problème 1 : la compréhension globale

Un visiteur pouvait comprendre un morceau de Dolist, mais pas forcément l'ensemble.

Il pouvait arriver sur Campaign sans bien voir les services associés.
Il pouvait découvrir Welkom Editor sans percevoir le lien avec Campaign.
Il pouvait lire un contenu de service sans comprendre la profondeur technologique derrière.
Il pouvait consulter le blog sans remonter facilement vers les offres.

Le risque, ce n'était pas l'absence d'information.

C'était l'éparpillement.

Problème 2 : le SEO dispersé

Le SEO principal était largement porté par dolist.com.

Mais une partie de l'offre vivait ailleurs.

Ça créait une situation assez classique :

  • le domaine principal porte l'autorité
  • les sites satellites portent des pages stratégiques
  • les ressources historiques vivent sur un autre périmètre
  • les intentions de recherche sont réparties
  • le maillage entre les sites n'est pas toujours optimal
  • les futures évolutions deviennent plus compliquées à piloter.

L'objectif n'était pas seulement de "rapatrier des pages".

L'objectif était de concentrer la valeur.

Problème 3 : l'architecture des offres

Dolist avait plusieurs niveaux d'offre :

  • des produits
  • des services
  • des expertises
  • des enjeux clients
  • des ressources
  • des preuves
  • des pages institutionnelles.

Mais tout n'était pas toujours organisé de manière évidente.

Il fallait donc reconstruire une hiérarchie.

Pas seulement une navigation.

Une vraie architecture d'information.

mindmap
  root((dolist.com refondu))
    Société
      Qui sommes-nous
      Notre histoire
      Notre équipe
      RSE
      Presse
      Carrières
      Contact
    Plateforme
      Campaign
      Campaign DevKit
      Welkom Editor
    Services
      Conseil
      Délivrabilité
      Studio
      Dataviz
      Formations
      Accompagnement
    Enjeux
      Communiquer avec vos publics
      Automatiser vos communications
      Améliorer la délivrabilité
      Sécuriser vos données
    Ressources
      Blog
      Guides
      Livres blancs
      Conférences
      Enquêtes
      Cas clients

Cette carte n'est pas juste une représentation du menu.

C'est la logique du site.

L'objectif : faire de dolist.com le point d'entrée unique

L'objectif de fond était simple à formuler :

Tout rapatrier sur dolist.com.

Mais derrière cette phrase, il y avait beaucoup de travail.

Il ne suffisait pas de déplacer des pages.

Il fallait :

  • repenser les parcours
  • clarifier les familles d'offres
  • créer des slugs cohérents
  • préserver le trafic SEO
  • éviter les pages doublons
  • reprendre les contenus historiques
  • produire de nouvelles pages
  • créer une logique entre produits, services et enjeux
  • prévoir les redirections
  • contrôler les formulaires
  • corriger les contenus importés
  • gérer les visuels
  • préparer la mise en ligne
  • organiser les retours internes après lancement.

Le projet ressemblait moins à une refonte classique qu'à une opération de consolidation.

flowchart LR
    A[Sites satellites] --> B[Inventaire]
    B --> C[Tri]
    C --> D[Fusion]
    D --> E[Réécriture]
    E --> F[Intégration dans dolist.com]
    F --> G[Redirections]
    G --> H[Monitoring SEO]

Les grandes phases du projet

Phase Activités principales Enjeu principal
Cadrage Comprendre l'écosystème, identifier les sites à rapatrier Ne rien oublier
Architecture Repenser les rubriques, Produits / Services / Enjeux Clarté de la structure
Production Réécrire les pages, créer les visuels, optimiser les metas Qualité éditoriale
Migration Préparer les redirections, contrôler les anciennes URLs Continuité SEO
Recette Tester les pages, vérifier les formulaires, corriger les détails Qualité finale
Lancement Mise en ligne, retours internes, ajustements continus Stabilité post-lancement

Principe de départ

Une refonte ne doit pas seulement rendre un site plus beau.
Elle doit rendre le système plus clair.

Les hypothèses de départ

Au début du projet, j'avais plusieurs hypothèses.

Certaines se sont confirmées.
D'autres ont évolué.

Hypothèse 1 : tout regrouper améliorerait la lisibilité

Celle-ci s'est confirmée.

Avoir un site unique permet de mieux montrer que Dolist repose sur un ensemble cohérent :

  • Campaign pour l'activation e-mail et SMS
  • Campaign DevKit pour les usages API et SI
  • Welkom Editor pour la conception d'e-mails
  • les services pour accompagner les projets
  • les enjeux pour traduire les besoins clients
  • les ressources pour nourrir la preuve et l'expertise.

La difficulté était de ne pas transformer ce regroupement en fourre-tout.

Hypothèse 2 : le SEO serait le principal risque

Celle-ci s'est confirmée aussi.

Quand 80 % de la valeur SEO est portée par le site principal, il ne faut pas jouer au plus malin.

Chaque page importante devait être traitée comme un actif.

Pas forcément à conserver à l'identique, mais à comprendre.

flowchart TD
    A[Page existante] --> B{Apporte du trafic SEO ?}
    B -->|Oui| C[Analyser intention + requêtes + backlinks]
    B -->|Non| D{A une valeur business ?}
    C --> E{Doit-elle rester autonome ?}
    E -->|Oui| F[Réécriture / optimisation]
    E -->|Non| G[Fusion + redirection]
    D -->|Oui| H[Repositionnement dans l'arborescence]
    D -->|Non| I[Suppression ou redirection vers page proche]

Hypothèse 3 : les pages "Enjeux" aideraient à relier SEO et business

C'était une hypothèse importante.

Les pages produits expliquent ce que Dolist propose.

Mais les utilisateurs ne cherchent pas toujours un produit.

Ils cherchent souvent à résoudre un problème :

  • mieux communiquer avec leurs publics
  • automatiser leurs communications
  • améliorer leur délivrabilité
  • sécuriser leurs données.

Les pages "Enjeux" permettaient de partir du besoin plutôt que de l'outil.

C'était aussi une manière de créer des ponts entre Campaign, Welkom Editor et les services.

Hypothèse 4 : les contenus existants seraient facilement réutilisables

Celle-là était plus optimiste.

En réalité, beaucoup de contenus devaient être repris.

Pas parce qu'ils étaient mauvais, mais parce qu'ils avaient été écrits pour des contextes différents :

  • anciens sites
  • anciennes pages
  • anciens positionnements
  • pages très produit
  • pages très service
  • contenus parfois trop longs
  • blocs hérités de WordPress
  • formulations qui ne correspondaient plus exactement à la nouvelle structure.

Le plus long n'a pas toujours été d'écrire.

Le plus long a souvent été de décider quoi garder.

L'architecture globale retenue

La nouvelle logique de dolist.com devait faire tenir plusieurs niveaux ensemble.

J'ai fini par raisonner comme ça :

flowchart TD
    A[dolist.com] --> B[Société]
    A --> C[Plateforme]
    A --> D[Services]
    A --> E[Enjeux]
    A --> F[Ressources]
    A --> G[Conversion]

    C --> C1[Campaign]
    C --> C2[Campaign DevKit]
    C --> C3[Welkom Editor]

    D --> D1[Conseil]
    D --> D2[Studio]
    D --> D3[Délivrabilité]
    D --> D4[Dataviz]
    D --> D5[Formations]

    E --> E1[Communiquer]
    E --> E2[Automatiser]
    E --> E3[Améliorer la délivrabilité]
    E --> E4[Sécuriser les données]

    F --> F1[Blog]
    F --> F2[Guides]
    F --> F3[Livres blancs]
    F --> F4[Conférences]
    F --> F5[Enquêtes]
    F --> F6[Cas clients]

    G --> G1[Contact]
    G --> G2[Formulaires]
    G --> G3[Newsletter]

Ce qui m'intéressait dans cette structure, c'était qu'elle évitait de tout faire porter aux pages produits.

Les produits ne sont pas seuls.

Ils sont entourés :

  • par des pages d'enjeux
  • par des services
  • par des preuves
  • par des contenus
  • par des pages institutionnelles
  • par des ressources téléchargeables.

C'est plus proche de la vraie valeur de Dolist.

pie title Répartition simplifiée des pages du nouveau dolist.com
    "Plateforme" : 15
    "Services" : 20
    "Enjeux" : 10
    "Ressources" : 40
    "Société" : 10
    "Conversion / contact" : 5

La différence entre "Plateforme", "Services" et "Enjeux"

C'était un point central.

Il fallait éviter que ces trois familles se marchent dessus.

Famille Rôle Exemple de question utilisateur
Plateforme Présenter les outils Dolist "Que permet Campaign ?"
Services Présenter l'accompagnement humain et expert "Qui peut m'aider à améliorer mes campagnes ?"
Enjeux Partir du problème client "Comment améliorer ma délivrabilité ?"
Ressources Nourrir, prouver, approfondir "Avez-vous un guide, un cas client, un exemple ?"
Société Rassurer et positionner Dolist "Qui est derrière cette solution ?"

Cette séparation a beaucoup aidé.

Parce qu'une même expertise peut apparaître à plusieurs endroits, mais avec un angle différent.

Par exemple, la délivrabilité :

  • dans Campaign, c'est une fonctionnalité et un socle technique
  • dans les services, c'est un accompagnement expert
  • dans les enjeux, c'est un problème client à résoudre
  • dans les ressources, ce sont des guides, conférences et contenus pédagogiques
  • dans la société, c'est un élément de positionnement historique.

Point important

Une bonne architecture ne supprime pas les répétitions.
Elle donne un rôle différent à chaque répétition.

Les choix de stack et d'outillage

La stack du projet n'avait rien de spectaculaire.

Et c'est plutôt une bonne chose.

Sur une refonte, l'enjeu principal n'est pas d'avoir les outils les plus sophistiqués.

C'est de garder une vision fiable de l'existant, des décisions et des statuts.

Les outils et supports utilisés

Besoin Outil / support Utilité réelle
Inventaire des pages Sitemap, exports, tableurs Ne pas oublier d'URLs importantes
Architecture Tableaux, plans, schémas Comparer les structures possibles
SEO Search Console, outils SEO, analyse manuelle Identifier les pages à préserver
Rédaction Documents structurés Travailler les contenus avant intégration
Intégration WordPress Construire les pages finales
Suivi Tableurs et checklists Piloter page par page
Tracking Matomo, formulaires, tags Vérifier la continuité de mesure
Recette Checklists manuelles Contrôler ce qui casse souvent
Communication interne Mail de lancement et boucle de retours Centraliser les bugs et coquilles

Deux périmètres distincts

Le tableau ci-dessus reflète surtout mon périmètre de travail. Mais le projet impliquait aussi un périmètre agence, bien distinct.

Mon périmètre : cadrage, architecture d'information, stratégie SEO, production et correction des contenus, choix des slugs, coordination interne, recette éditoriale et fonctionnelle.

Périmètre agence : conception graphique et direction artistique, maquettes, intégration WordPress, développement et paramétrage technique, composants, ajustements responsive, mise en production.

Je suis resté sur des outils simples pour ma partie parce que le projet avait déjà assez de complexité.

Ajouter une couche d'outil trop lourde aurait probablement ralenti plus qu'aidé.

Pourquoi le tableur reste difficile à remplacer

Pour un projet comme celui-ci, le tableur est presque imbattable.

Parce qu'une refonte est fondamentalement une table de correspondance.

ancienne_url,nouvelle_url,type_page,statut,priorite_seo,action,commentaire
https://campaign.dolist.com/...,https://dolist.com/plateforme/campaign/,Produit,À migrer,Haute,Fusionner,"Page stratégique"
https://email-builder.dolist.com/...,https://dolist.com/plateforme/welkom-editor/,Produit,À migrer,Haute,Réécrire,"Conserver les bénéfices clés"
https://services.dolist.com/...,https://dolist.com/services/studio/,Service,À intégrer,Moyenne,Réécrire,"Reprendre l'approche Studio"

Un outil plus élégant peut aider à documenter.

Mais pour suivre des URLs, des statuts, des redirections, des titres, des metas, des priorités, le tableur reste très efficace.

Construction étape par étape

Le rôle de l'agence

Je n'ai pas conçu seul le site : l'agence a porté toute la partie design, intégration et production technique.

Concrètement, elle s'est occupée de la direction artistique, des maquettes, de l'intégration dans WordPress, du développement des composants, des ajustements responsive et de la mise en production.

De mon côté, j'ai travaillé sur le fond : l'arborescence, la structuration des pages, les contenus, le SEO, les redirections, la coordination interne et la recette.

La difficulté, côté pilotage, était de garder une vision cohérente sur les deux périmètres en même temps. Ce qui est dans les maquettes, ce qui est dans les textes, ce que ça implique pour le SEO, ce qui doit s'aligner avec les offres.

1. Partir de l'existant, même quand il est imparfait

La première étape a été de regarder l'existant sans chercher immédiatement à le corriger.

C'est important.

Quand on arrive sur une refonte, on a envie de nettoyer tout de suite :

  • cette page est trop longue
  • ce slug est bizarre
  • cette rubrique n'est plus claire
  • ce contenu est redondant
  • cette page ne devrait plus exister.

Mais avant de supprimer, il faut comprendre.

Une page peut être moche mais utile.
Un vieux contenu peut encore capter une requête.
Une page mal rangée peut être utilisée dans une campagne.
Un formulaire oublié peut encore générer des demandes.

J'ai donc essayé de distinguer trois choses :

Question Pourquoi elle compte
Est-ce que la page existe ? Inventaire brut
Est-ce qu'elle sert encore ? Valeur réelle
Est-ce qu'elle doit rester comme ça ? Décision de refonte

Ce sont trois questions différentes.

2. Repenser les pages produits

Les pages produits étaient centrales.

Il fallait présenter :

  • Campaign
  • Campaign DevKit
  • Welkom Editor.

Mais sans les isoler complètement du reste.

Campaign

Campaign devait être présenté comme la plateforme d'activation e-mail et SMS.

Pas seulement comme un outil d'envoi.

Il fallait faire ressortir :

  • la centralisation des données
  • les campagnes marketing
  • les messages transactionnels
  • l'automatisation
  • les landing pages
  • la segmentation
  • la délivrabilité
  • la sécurité
  • les API
  • les performances
  • les démarches responsables.

Le risque était de faire une page trop longue, parce que Campaign couvre beaucoup de choses.

J'ai donc travaillé avec une logique de blocs :

flowchart TD
    A[Page Campaign] --> B[Hero clair]
    A --> C[Cas d'usage principaux]
    A --> D[Centralisation data]
    A --> E[Création messages]
    A --> F[Activation e-mail & SMS]
    A --> G[Automation / transactionnel]
    A --> H[Délivrabilité]
    A --> I[Sécurité / RGPD]
    A --> J[Analyse performances]
    A --> K[CTA final]

L'enjeu était de montrer la profondeur sans perdre le lecteur.

Campaign DevKit

Campaign DevKit était un sujet plus technique.

Là, il fallait éviter deux erreurs :

  • trop simplifier et perdre les profils techniques
  • trop détailler et rendre la page illisible pour les décideurs.

L'angle naturel était :

Utiliser les fonctionnalités Campaign depuis son propre système d'information.

Donc parler :

  • API
  • connectivité
  • SI
  • CRM
  • CDP
  • ERP
  • e-commerce
  • données
  • flux sécurisés
  • transactionnel
  • webhooks
  • imports / exports
  • documentation.

C'est typiquement une page où le contenu doit rassurer sans devenir une documentation technique complète.

Welkom Editor

Welkom Editor avait un autre rôle.

Il fallait le présenter comme un email builder collaboratif, mais surtout comme un outil qui répond à des problèmes très concrets :

  • produire plus vite
  • garder une cohérence de marque
  • créer des emails responsive
  • améliorer l'accessibilité
  • faciliter la collaboration
  • exporter vers différents routeurs
  • éviter de repartir de zéro à chaque campagne.

Là aussi, le défi était de ne pas écrire une page "outil SaaS" générique.

Le sujet n'est pas "un builder drag & drop".

Le sujet est plutôt :

Comment créer des emails propres, accessibles, compatibles et réutilisables sans dépendre à chaque fois d'une intégration complète.

3. Réintégrer les services sans les réduire à une liste

Le site services.dolist.com contenait beaucoup de valeur.

Mais rapatrier les services dans dolist.com demandait de les rendre plus lisibles.

Il fallait notamment traiter :

  • le conseil en stratégie e-mail et SMS
  • la délivrabilité
  • le Studio
  • la dataviz
  • les formations
  • l'accompagnement technique
  • la gestion opérationnelle.

Le risque était de créer une page "services" interminable.

J'ai préféré penser les services comme des réponses à des situations.

Situation client Service associé
"Je veux améliorer mes performances e-mail" Conseil marketing / délivrabilité
"Je veux produire des emails plus qualitatifs" Studio / email design / intégration HTML
"Je veux mieux piloter mes résultats" Dataviz / dashboards
"Je veux connecter mes outils" Accompagnement API / data
"Je veux monter en compétences" Formations
"Je veux déléguer l'opérationnel" Gestion de campagnes

Cette logique rend les services plus concrets.

4. Créer les pages "Enjeux"

Les pages "Enjeux" ont été un vrai point structurant.

Elles permettent de parler moins depuis l'offre et plus depuis le besoin.

Les quatre grandes pages étaient :

  • Communiquer avec vos publics
  • Automatiser vos communications
  • Améliorer la délivrabilité
  • Sécuriser vos données

Ce sont des pages importantes parce qu'elles font le lien entre plusieurs parties du site.

Exemple avec "Améliorer la délivrabilité" :

flowchart TD
    A[Améliorer la délivrabilité] --> B[Campaign]
    A --> C[Pack délivrabilité]
    A --> D[Experts délivrabilité]
    A --> E[Authentification SPF DKIM DMARC]
    A --> F[Gestion bounces plaintes désabonnements]
    A --> G[Supervision O.P.E.R.A.]
    A --> H[Guides et ressources]

Cette page ne remplace pas la page Campaign.

Elle ne remplace pas non plus une page service.

Elle sert d'entrée par problème.

C'est une logique plus proche de ce que cherche l'utilisateur.

5. Reprendre les pages société

Les pages société avaient un rôle différent.

Elles ne sont pas là uniquement pour "faire institutionnel".

Elles doivent aider à comprendre :

  • qui est Dolist
  • d'où vient l'entreprise
  • ce qu'elle défend
  • pourquoi elle parle de délivrabilité, de RGPD, de sécurité et de numérique responsable
  • qui compose l'équipe
  • comment l'entreprise se positionne.

Les pages concernées étaient notamment :

  • Qui sommes-nous
  • Notre histoire
  • Notre équipe
  • RSE
  • Carrières
  • Espace presse
  • Contact.

Sur ces pages, le piège était de produire du contenu trop corporate.

Il fallait rester sobre, crédible, incarné.

Pas besoin de surjouer l'émotion.

Juste expliquer clairement ce qu'est Dolist aujourd'hui.

6. Réorganiser les ressources

Les ressources étaient un gros morceau.

Dolist avait beaucoup de contenus :

  • articles
  • guides
  • livres blancs
  • conférences
  • enquêtes
  • cas clients
  • webinars
  • vidéos
  • podcasts
  • infographies.

Le risque avec une bibliothèque de ressources, c'est qu'elle devienne une décharge bien rangée.

Tout est là, mais personne ne trouve rien.

L'enjeu était donc de mieux organiser les formats.

flowchart TD
    A[Ressources] --> B[Blog]
    A --> C[Guides]
    A --> D[Livres blancs]
    A --> E[Conférences]
    A --> F[Enquêtes]
    A --> G[Cas clients]

    C --> C1[Délivrabilité]
    C --> C2[Marketing automation]
    C --> C3[RGPD]
    C --> C4[Email design]
    C --> C5[Acquisition]

    G --> G1[Secteur public]
    G --> G2[Retail]
    G --> G3[Tourisme]
    G --> G4[Associations]

Il fallait aussi retravailler les visuels, les titres, les metas, les ALT, les descriptions.

Ce travail est répétitif.

Mais il est important.

Une ressource mal nommée, mal décrite ou mal illustrée perd une partie de sa valeur.

Le travail SEO

Ne pas traiter le SEO comme une couche de fin

Sur une refonte, le SEO ne doit pas arriver à la fin.

Sinon, il devient une checklist de réparation.

Dans ce projet, le SEO était présent partout :

  • dans l'arborescence
  • dans les slugs
  • dans les titres
  • dans les metas
  • dans les H1
  • dans les redirections
  • dans le maillage interne
  • dans les ressources
  • dans les pages enjeux
  • dans les pages produits
  • dans le traitement des anciens sites.

Le vrai sujet SEO n'était pas uniquement d'optimiser des balises.

C'était de ne pas casser l'existant tout en construisant une structure plus saine.

Niveau de risque estimé par chantier

Chantier Risque estimé Raison principale
SEO ★★★★★ Très élevé Trafic organique existant sur tous les sites
Redirections ★★★★★ Très élevé Toute URL oubliée = 404, perte SEO
Contenus ★★★★☆ Élevé Arbitrages complexes, réécriture longue
Tracking ★★★☆☆ Moyen Continuité des données avant/après
Formulaires ★★★☆☆ Moyen Formulaires fonctionnels = conversions
Design ★★☆☆☆ Modéré Risque visible mais plus facilement réversible

Les slugs

J'ai essayé de garder des slugs lisibles et cohérents.

Pas des slugs bourrés de mots-clés.

Pas des slugs trop internes.

Pas des slugs qui vieillissent mal.

Exemples de logique :

/plateforme/campaign/
/plateforme/campaign-devkit/
/plateforme/welkom-editor/

/services/conseil-strategie-email-sms/
/services/studio-email-design/
/services/delivrabilite-email/
/services/dataviz-marketing/

/enjeux/communiquer-publics/
/enjeux/automatiser-communications/
/enjeux/ameliorer-delivrabilite/
/enjeux/securiser-donnees/

Le slug doit être assez précis pour être utile, mais assez stable pour durer.

Les titles et metas

J'ai aussi beaucoup travaillé les titles et metas.

Pas comme un exercice cosmétique.

Comme une manière de clarifier l'intention de chaque page.

Un bon title, dans ce contexte, devait :

  • rester court
  • être compréhensible
  • porter l'intention principale
  • éviter le remplissage
  • ne pas promettre n'importe quoi
  • rester aligné avec la page.

Exemple de logique :

Page Intention
Campaign Plateforme e-mail & SMS
Campaign DevKit API et connectivité
Welkom Editor Email builder collaboratif
Délivrabilité Améliorer l'aboutissement des emails
Dataviz Piloter les performances marketing
Cas clients Montrer des preuves concrètes

Ce travail est minutieux, mais il oblige à clarifier les pages.

Si je n'arrive pas à résumer une page en un title propre, c'est souvent que la page elle-même n'est pas encore assez claire.

Les redirections

La migration des anciens sites vers dolist.com était un point sensible.

Il fallait éviter :

  • les redirections vers la homepage par facilité
  • les chaînes de redirection
  • les boucles
  • les oublis d'anciennes URLs
  • les ressources perdues
  • les pages satellites laissées en suspens
  • les slugs incohérents
  • les pages supprimées sans équivalent.

Structure type du plan :

ancienne_url,nouvelle_url,type,priorite,commentaire
https://campaign.dolist.com/fonctionnalites/centraliser-donnees/,https://dolist.com/plateforme/campaign/,301,haute,"Fonctionnalité intégrée dans page Campaign"
https://email-builder.dolist.com/fonctionnalites/email-builder-collaboratif/,https://dolist.com/plateforme/welkom-editor/,301,haute,"Page Welkom Editor"
https://services.dolist.com/studio/,https://dolist.com/services/studio-email-design/,301,moyenne,"Service Studio"

Point de vigilance

Une redirection n'est pas seulement une opération technique.
C'est une décision éditoriale et SEO : on choisit où transférer une intention.

Le travail de contenu

Le plus long : dire moins, mais mieux

Le plus difficile n'a pas été de produire du texte.

Le plus difficile a été de choisir.

Sur un projet comme celui-ci, il y a énormément de choses à dire :

  • les fonctionnalités
  • les bénéfices
  • les expertises
  • les preuves
  • les engagements
  • les cas d'usage
  • les détails techniques
  • les services associés
  • les ressources complémentaires.

Mais tout dire au même endroit rend les pages lourdes.

J'ai donc essayé de structurer les contenus avec une logique plus progressive :

flowchart TD
    A[Problème ou besoin] --> B[Réponse Dolist]
    B --> C[Ce que ça permet concrètement]
    C --> D[Comment ça fonctionne]
    D --> E[Preuves / ressources / cas clients]
    E --> F[Action suivante]

L'idée était simple :

ne pas forcer le lecteur à tout comprendre d'un coup.

Éviter le ton "landing page SaaS"

C'était un point important.

Je ne voulais pas que les pages ressemblent à des tunnels de conversion génériques.

Le vocabulaire devait rester :

  • professionnel
  • précis
  • sobre
  • concret
  • orienté usage
  • crédible.

Pas besoin de promettre une "révolution".

Dolist a déjà une vraie profondeur métier.

Le sujet était de la rendre lisible.

Nettoyer l'ancien HTML

Une partie très concrète du projet a aussi été le nettoyage de contenus hérités.

Des blocs issus d'anciens WordPress, des spans inutiles, des listes mal formatées, des styles inline, des morceaux de code qui traînent, des liens cassés ou sautés.

Exemple typique :

<h2><span class="TextRun MacChromeBold SCXW58363964 BCX0">Campaign, un gage de sécurité pour vos données</span></h2>
<ul>
  <li data-leveltext="" data-font="Symbol" data-listid="15">
    <span data-contrast="auto">Un <strong>socle technique optimisé...</strong></span>
  </li>
</ul>

À transformer en quelque chose de propre :

<h2>Campaign, un gage de sécurité pour vos données</h2>

<ul>
  <li>Un <strong>socle technique optimisé en matière de sécurité des données</strong>.</li>
  <li>Des accès sécurisés et une gestion fine des droits utilisateurs.</li>
  <li>Des échanges de données via des protocoles standards et sécurisés.</li>
</ul>

Ce n'est pas spectaculaire.

Mais c'est nécessaire.

Le travail visuel

Trouver un style cohérent

La refonte ne concernait pas seulement les textes.

L'agence a conçu et décliné un univers visuel complet : rendu plus moderne, plus SaaS, plus premium, fonds sombres, interfaces floutées quand nécessaire, mockups plus propres.

Mon rôle sur cette partie était de challenger, valider, demander des ajustements, et surtout veiller à la cohérence entre les visuels et les offres réelles.

L'enjeu n'était pas de faire joli pour faire joli.

Les visuels devaient aider à comprendre, pas décorer.

Concrètement, je veillais à ce que chaque visuel respecte quelques contraintes :

  • montrer Campaign sans exposer des données sensibles
  • illustrer Welkom Editor sans créer de fausses fonctionnalités
  • présenter les guides avec un style homogène
  • éviter les visuels trop décoratifs
  • garder une cohérence entre les pages offres, ressources et société.

Les visuels de ressources

Les guides et livres blancs avaient besoin d'une vraie cohérence.

L'idée retenue : un rendu sobre, premium, avec un mockup de guide ouvert, sur fond bleu nuit, en reprenant les pages du document source plutôt que d'ajouter des éléments décoratifs sans lien.

Ce choix fonctionne bien parce qu'il donne :

  • de la cohérence
  • une impression de ressource réelle
  • un rendu plus qualitatif
  • une continuité entre les contenus.

Les ALT, titres et descriptions d'images

C'est une partie répétitive, mais importante.

Chaque image devait avoir :

  • un nom de fichier propre
  • un ALT utile
  • un titre
  • parfois une légende
  • parfois une description.

Pas pour "faire du SEO image" de manière artificielle.

Mais parce que ça participe à la qualité globale du site.

Exemple :

Fichier :
guide-pratique-travailler-la-delivrabilite-des-emails.webp

ALT :
Guide Dolist sur les bonnes pratiques pour travailler la délivrabilité des emails.

Titre :
Guide pratique : travailler la délivrabilité des emails

Légende :
Un guide pour comprendre les leviers techniques et marketing qui influencent la délivrabilité email.

Description :
Visuel du guide Dolist consacré à la délivrabilité email, présenté sous forme de mockup ouvert sur fond bleu nuit.

Les formulaires, le tracking et les détails qu'on oublie vite

Une refonte ne s'arrête pas aux pages visibles.

Il y a aussi toutes les connexions autour.

Formulaires

Il fallait vérifier :

  • les formulaires de contact
  • les formulaires ressources
  • l'inscription newsletter
  • les messages de confirmation
  • les notifications internes
  • les mentions RGPD
  • les redirections après soumission
  • les champs
  • les consentements.

Une page peut être très belle et parfaitement inutile si le formulaire ne fonctionne pas.

Tracking

Il fallait aussi penser à la mesure.

  • Matomo
  • événements
  • formulaires
  • pages vues
  • clics
  • conversions
  • ressources téléchargées
  • éventuels changements d'URLs
  • cohérence des données avant / après lancement.

Le tracking est souvent traité comme un sujet secondaire.

Mais après la mise en ligne, si les données ne sont pas propres, il devient difficile de comprendre ce qui se passe.

Open Graph et image de partage

Un détail qui revient souvent : l'image qui s'affiche quand on partage une URL.

Ce n'est pas toujours celle qu'on croit.

Il faut vérifier :

  • l'image Open Graph
  • les réglages Yoast
  • les images par défaut
  • les caches
  • les aperçus LinkedIn
  • les anciennes images encore récupérées.

Ce genre de détail peut sembler mineur.

Mais il participe à la perception du site.

La recette

Recetter, ce n'est pas cliquer vite fait

La recette est une phase très sous-estimée.

Dans ce projet, il fallait vérifier plusieurs couches :

Zone À contrôler
SEO Title, meta, H1, canonicals, indexabilité
URLs Slugs, anciennes URLs, redirections
Contenu Coquilles, textes manquants, doublons
Design Responsive, espacements, cohérence visuelle
Images Poids, ALT, affichage, recadrage
Formulaires Envoi, notification, confirmation
Tracking Matomo, événements, conversions
Navigation Menu, footer, liens internes
Accessibilité Hiérarchie, contrastes, textes alternatifs
Performance Images, scripts, chargement

Checklist type :

## Recette page

- [ ] URL finale validée
- [ ] Redirection ancienne URL testée
- [ ] Title renseigné
- [ ] Meta description renseignée
- [ ] H1 unique
- [ ] H2 cohérents
- [ ] Aucun lien cassé
- [ ] Images optimisées
- [ ] ALT renseignés
- [ ] CTA fonctionnels
- [ ] Formulaire testé si présent
- [ ] Page responsive mobile
- [ ] Page responsive tablette
- [ ] Page responsive desktop
- [ ] Tracking vérifié
- [ ] Page indexable si nécessaire

Les bugs et coquilles après lancement

Même avec une bonne recette, un site lancé révèle toujours des choses.

Des coquilles.
Des espacements.
Des liens.
Des pages qui réagissent différemment en production.
Des détails que personne n'avait vus en préproduction.

C'est pour ça qu'on a prévu une logique de retours internes.

Pas "envoyez-moi un mail à chaque coquille".

Plutôt :

centraliser des retours complets, exploitables, avec URL, capture et description du problème.

C'est beaucoup plus efficace.

Ce qui a été plus compliqué que prévu

1. L'arborescence

Sur le papier, organiser un site semble simple.

Dans la réalité, chaque rubrique peut être discutée.

Est-ce que la délivrabilité est un service, un enjeu, une fonctionnalité ou une expertise ?
Réponse : un peu tout ça.

Est-ce que Welkom Editor doit être dans "plateforme" ou avoir une entrée autonome ?
Est-ce que les formations sont des services, des ressources ou une page à part ?
Est-ce que les cas clients doivent être dans ressources ou dans preuve ?
Est-ce que les pages société doivent être visibles dans le menu principal ?

Il faut accepter que l'architecture parfaite n'existe pas.

Il faut choisir l'architecture la plus utile.

2. Les pages à double rôle

Certaines pages ont plusieurs fonctions.

Une page peut être à la fois :

  • SEO
  • commerciale
  • pédagogique
  • rassurante
  • support de preuve
  • porte d'entrée vers un formulaire.

C'est là que les arbitrages deviennent subtils.

Si on optimise trop pour le SEO, la page devient froide.
Si on optimise trop pour la conversion, elle devient agressive.
Si on explique trop, elle devient longue.
Si on simplifie trop, elle devient vague.

Le bon équilibre se trouve rarement du premier coup.

3. Les contenus historiques

Certains contenus existaient depuis longtemps.

Ils avaient parfois été modifiés, repris, déplacés, enrichis.

Il fallait décider :

  • ce qu'on conserve
  • ce qu'on modernise
  • ce qu'on fusionne
  • ce qu'on supprime
  • ce qu'on transforme en ressource
  • ce qu'on redirige.

Ce travail est plus éditorial que technique.

Mais il a un impact SEO très concret.

4. Les détails WordPress

WordPress permet d'avancer vite.

L'agence gérait l'intégration et les ajustements techniques dans le CMS. De mon côté, mon travail portait surtout sur la validation des pages, les corrections de contenu, la cohérence SEO, les formulaires et les retours de recette.

Mais le CMS peut aussi créer beaucoup de petites frictions, des deux côtés :

  • blocs mal imbriqués
  • styles hérités
  • HTML ajouté par copier-coller
  • marges incohérentes
  • images trop lourdes
  • ancres non prévues
  • comportements responsive à reprendre
  • contenus modifiés directement dans l'éditeur.

Le CMS n'est jamais neutre.

Il influence la manière dont le site est réellement construit — et il oblige à une communication constante entre celui qui intègre et celui qui valide.

Ce qui a bien fonctionné

1. Partir des enjeux clients

Les pages "Enjeux" ont aidé à sortir d'une logique purement catalogue.

Au lieu de dire uniquement :

voici nos produits et services,

le site peut aussi dire :

voici les problèmes que nous aidons à résoudre.

C'est plus naturel pour un visiteur.

2. Donner une vraie place aux services

Les services Dolist ne sont pas accessoires.

Ils font partie de la valeur.

Conseil, délivrabilité, Studio, dataviz, formations, accompagnement technique : ce sont des sujets structurants.

Le fait de les rapatrier dans dolist.com permet de mieux montrer l'alliance entre technologie et accompagnement.

3. Mieux connecter les ressources

Les ressources ne doivent pas vivre à côté du site.

Elles doivent soutenir les pages importantes.

Un guide sur la délivrabilité doit pouvoir renforcer une page sur la délivrabilité.
Un cas client doit pouvoir rassurer depuis une page offre.
Une conférence doit pouvoir nourrir une expertise.
Un livre blanc doit pouvoir prolonger une page enjeu.

flowchart TD
    A[Page enjeu] --> B[Page produit]
    A --> C[Page service]
    A --> D[Guide]
    A --> E[Cas client]
    A --> F[Conférence]

    D --> A
    E --> A
    F --> A

C'est ce maillage qui donne de la profondeur au site.

4. Garder une base évolutive

Le site lancé n'est pas une fin.

C'est une base.

Cette idée est importante.

Une refonte ne règle pas tout.

Elle crée une structure plus saine pour continuer à améliorer :

  • les contenus
  • les pages SEO
  • les ressources
  • les formulaires
  • les visuels
  • le maillage
  • les conversions
  • la mesure.

Il faut accepter qu'un site vivant ne soit jamais "terminé".

Ce que j'ai appris

Une refonte est un projet d'architecture avant d'être un projet graphique

Le design compte.

Mais il arrive après une question plus profonde :

Qu'est-ce qu'on veut rendre compréhensible ?

Si la structure est floue, le design ne sauvera pas le site.

Il pourra le rendre plus agréable, mais pas forcément plus utile.

Le SEO est une contrainte saine

On présente parfois le SEO comme une contrainte pénible.

Sur ce projet, je l'ai plutôt vu comme une discipline utile.

Le SEO force à se poser de bonnes questions :

  • à quoi sert cette page ?
  • quelle intention couvre-t-elle ?
  • est-elle redondante ?
  • mérite-t-elle une URL propre ?
  • faut-il la fusionner ?
  • comment la relier aux autres ?
  • comment éviter de perdre son historique ?

Le SEO oblige à être rigoureux.

Les contenus sont des décisions

Un contenu n'est pas juste du texte à produire.

C'est une décision sur :

  • ce qu'on met en avant
  • ce qu'on laisse de côté
  • le vocabulaire qu'on choisit
  • la promesse qu'on accepte de porter
  • le niveau de détail qu'on donne
  • le chemin qu'on propose au lecteur.

C'est pour ça que la rédaction prend du temps.

Les petits détails font la qualité perçue

Un site peut perdre en crédibilité sur des détails :

  • une image mal recadrée
  • une méta oubliée
  • une URL étrange
  • un lien cassé
  • une faute dans un H1
  • un formulaire qui ne confirme rien
  • un visuel trop lourd
  • une page qui charge mal sur mobile
  • une image de partage incohérente.

Ces détails ne sont pas secondaires.

Ils construisent l'expérience.

Ce que je referais autrement

1. Documenter encore plus tôt les décisions

Avec le recul, je documenterais davantage les arbitrages.

Pas sous forme de longs comptes rendus.

Plutôt avec de petites fiches de décision.

## Décision : créer une rubrique Enjeux

Contexte :
Les pages produits ne suffisent pas à couvrir toutes les intentions utilisateurs.

Décision :
Créer quatre pages orientées besoins :
- communiquer avec vos publics
- automatiser vos communications
- améliorer la délivrabilité
- sécuriser vos données.

Impact :
Ces pages servent de pont entre produits, services et ressources.

Point de vigilance :
Éviter qu'elles deviennent redondantes avec les pages produits.

Ce type de note aurait été utile pour garder une trace claire des choix.

2. Automatiser davantage les contrôles

Certains contrôles auraient pu être automatisés plus tôt :

  • status codes
  • titles manquants
  • metas manquantes
  • H1 absents
  • liens cassés
  • images sans ALT
  • redirections en chaîne
  • pages noindex involontaires.

Exemple de script simple :

import requests
from bs4 import BeautifulSoup

urls = [
    "https://dolist.com/",
    "https://dolist.com/plateforme/campaign/",
    "https://dolist.com/plateforme/welkom-editor/",
]

for url in urls:
    response = requests.get(url, timeout=10)
    soup = BeautifulSoup(response.text, "html.parser")

    title = soup.title.string.strip() if soup.title else None
    h1 = soup.find("h1")
    meta = soup.find("meta", attrs={"name": "description"})

    print({
        "url": url,
        "status": response.status_code,
        "title": title,
        "h1": h1.get_text(strip=True) if h1 else None,
        "meta": meta["content"] if meta and meta.get("content") else None
    })

Ce n'est pas très complexe.

Mais sur des dizaines ou centaines de pages, ça peut éviter beaucoup d'oublis.

3. Créer plus tôt une cartographie du maillage interne

Le maillage interne est souvent traité page par page.

J'aimerais le voir davantage comme un graphe.

graph TD
    A[Campaign] --> B[Automatiser vos communications]
    A --> C[Améliorer la délivrabilité]
    A --> D[Sécuriser vos données]
    B --> E[Guide marketing automation]
    C --> F[Guide délivrabilité]
    D --> G[Page RGPD / sécurité]
    F --> C
    E --> B

Cette vision permettrait de mieux comprendre quelles pages soutiennent quelles intentions.

4. Prévoir un monitoring post-lancement plus industrialisé

Après une mise en ligne, j'aimerais avoir un tableau de bord dédié :

Indicateur Pourquoi
404 Détecter les anciennes URLs oubliées
Redirections Identifier les chaînes ou erreurs
Pages indexées Repérer les anomalies SEO
Trafic organique Suivre les variations
Formulaires Vérifier les conversions
Temps de chargement Surveiller la performance
Clics CTA Comprendre les parcours
Téléchargements ressources Mesurer l'engagement

Un workflow automatisé pourrait très bien envoyer un résumé quotidien pendant les premières semaines.

C'est un sujet que j'aimerais rapprocher de mes autres expérimentations autour de Scrapy, n8n et des pipelines de données.

Liens avec mes autres projets

Cette refonte rejoint plusieurs sujets que j'ai déjà explorés ailleurs.

Détection technique avec Scrapy

Dans mon projet de détection de technologies web, je partais déjà d'une idée similaire : transformer un ensemble de sites en données exploitables.

Ici, le contexte est différent, mais la logique reste proche :

  • crawler
  • inventorier
  • qualifier
  • décider
  • suivre.

Voir : Construire un détecteur de technologies web avec Scrapy

Signaux d'expansion WTTJ / LinkedIn

Dans mon article sur les signaux d'expansion, je travaillais sur la détection d'indices faibles.

Sur une refonte, il y a aussi des signaux faibles :

  • une page qui génère peu de trafic mais convertit
  • une ressource ancienne encore très consultée
  • une URL jamais visible dans le menu mais souvent partagée
  • un formulaire secondaire mais utile
  • une page mal rangée mais stratégique.

Voir : Détecter les signaux d'expansion avec WTTJ, LinkedIn et n8n

Veille concurrentielle multi-source

La refonte m'a aussi rappelé l'importance de croiser les sources.

On ne peut pas décider uniquement avec un sitemap.

Il faut regarder :

  • les données SEO
  • les contenus
  • les parcours
  • les offres
  • les retours internes
  • les contraintes techniques
  • les besoins commerciaux.

Voir : Construire une veille concurrentielle multi-source

Machine à leads SDR

Enfin, le sujet rejoint aussi la logique de conversion.

Un site n'est pas juste un support de présentation.

C'est une brique dans un système plus large :

  • acquisition
  • qualification
  • nurturing
  • prise de contact
  • transmission aux équipes commerciales
  • analyse des signaux.

Voir : Construire une machine à leads SDR

Questions fréquentes

Pourquoi consolider plusieurs sites en un seul domaine ?

La fragmentation multi-sites dilue l'autorité SEO, complique la navigation pour l'utilisateur et rend difficile la présentation cohérente d'une offre intégrée. Consolider sur un domaine unique concentre la valeur SEO sur un seul périmètre, simplifie le maillage interne et donne une vision claire de l'ensemble de l'écosystème.

Dans le cas de Dolist, 4 domaines portaient des pages stratégiques sans se renforcer mutuellement. Le rapatriement vers dolist.com visait à corriger ce problème structurel.

Comment préserver le SEO lors d'une refonte de site ?

Il faut traiter chaque page existante comme un actif : analyser son trafic, identifier ses requêtes, ses backlinks et ses intentions de recherche, puis décider si elle doit être conservée telle quelle, réécrite, fusionnée avec une autre, ou redirigée.

Le SEO ne doit pas arriver en fin de projet sous forme de checklist — il doit piloter les arbitrages depuis le début : choix des slugs, structure des pages, décisions de fusion, plan de redirections.

Comment planifier les redirections 301 lors d'une migration multi-sites ?

La méthode la plus fiable reste le tableur de correspondance : ancienne URL, nouvelle URL, type de page, priorité SEO, statut et commentaire. Il faut éviter à tout prix les redirections vers la homepage "par facilité", les chaînes de redirections et les URLs oubliées.

Chaque redirection est une décision éditoriale et SEO : on choisit où transférer une intention de recherche. Sur des dizaines ou centaines de pages, ce travail demande de la rigueur et un suivi rigoureux.

Quelle architecture d'information pour un site B2B complexe ?

La clé est de distinguer clairement les familles : Plateforme (les outils), Services (l'accompagnement humain), Enjeux (les problèmes clients), Ressources (les preuves et contenus), Société (le positionnement). Cette structure évite que les pages se marchent dessus.

Une même expertise peut apparaître dans plusieurs familles — la délivrabilité, par exemple, est à la fois une fonctionnalité Campaign, un service expert, un enjeu client, et un sujet de ressources. L'architecture donne un rôle différent à chaque occurrence plutôt que de les supprimer.

Quels sont les principaux risques d'une refonte web ?

Les risques les plus élevés sont le SEO (perte de trafic organique liée à des URLs changées ou mal redirigées) et les redirections (URLs oubliées qui génèrent des 404 et diluent le PageRank). Viennent ensuite la qualité du contenu, la continuité du tracking, et le bon fonctionnement des formulaires.

Une recette rigoureuse page par page et un monitoring post-lancement sur les 404, les positions SEO et les conversions sont indispensables.

Quels outils pour piloter une refonte web efficacement ?

Le tableur reste difficile à remplacer pour les correspondances URL et le suivi des statuts page par page. La Search Console et un outil SEO (Screaming Frog, Ahrefs, SEMrush) sont indispensables pour l'audit des pages existantes.

Des scripts Python simples (requests + BeautifulSoup) permettent d'automatiser les contrôles qualité sur les titles, metas, H1 et status codes sur l'ensemble du site. C'est peu de code, mais ça évite beaucoup d'oublis sur des projets de grande ampleur.

Conclusion

Cette refonte m'a surtout appris une chose :

un site web d'entreprise finit toujours par raconter son organisation interne, même quand ce n'était pas l'intention.

Au fil des années, les pages s'ajoutent.
Les offres évoluent.
Les contenus s'accumulent.
Les sites satellites apparaissent.
Les ressources se multiplient.
Les priorités changent.

Et un jour, il faut reprendre le fil.

La refonte de dolist.com, pour moi, c'était ça.

Reprendre le fil.

Comprendre ce qui existait.
Identifier ce qui avait encore de la valeur.
Regrouper ce qui devait l'être.
Réécrire ce qui était devenu flou.
Préserver ce qui fonctionnait.
Créer une architecture plus saine.
Accepter que tout ne serait pas parfait au lancement.
Construire une base qui pourrait évoluer.

Ce projet n'a pas été un travail solitaire. L'agence a évidemment porté une grande partie de la conception, de l'intégration et de la production technique. Ce retour raconte surtout la manière dont j'ai vécu et piloté la refonte côté Dolist : le SEO, les contenus, l'architecture, la validation et les arbitrages.

Je ne vois pas ce projet comme un "nouveau site terminé".

Je le vois plutôt comme une nouvelle fondation.

Une fondation plus claire pour présenter Dolist, ses produits, ses services, ses expertises, ses ressources et ses engagements.

Et c'est peut-être ça, au fond, une bonne refonte.

Pas une rupture spectaculaire.

Un réalignement.

Entre ce que l'entreprise est devenu, ce que les utilisateurs doivent comprendre, ce que le SEO a construit dans le temps, et ce que le site doit permettre demain.