Le KPI dont personne ne parle au moment du brief
Quand on discute d'une refonte de site avec un fondateur, les conversations tournent presque toujours autour des mêmes métriques : score PageSpeed, taux de conversion, design qui transmet la marque, SEO. Toutes légitimes.
Mais il y a un indicateur qui ne sort jamais dans le brief initial — et qui détermine pourtant la moitié du retour sur investissement réel d'un site web : la productivité éditoriale de l'équipe interne.
Combien de temps faut-il pour publier un nouvel article de blog, du Word brut à la mise en ligne ? Combien de minutes pour modifier une accroche commerciale sur la home ? Combien de clics pour ajouter une étude de cas avec galerie d'images ? Et surtout : combien de fois l'équipe marketing renonce à toucher au site parce que c'est trop pénible, et accumule à la place du backlog dans un Notion qui ne sortira jamais ?

Ces moments perdus ne se voient nulle part dans un rapport Google Analytics. Ils se voient dans le rythme de production de contenu, dans la fraîcheur du site, dans le sentiment d'autonomie d'une équipe — et indirectement, dans tout le reste.
Pourquoi WordPress + page builder reste un piège
Je veux être clair : WordPress n'est pas mort, et il reste un excellent choix pour beaucoup de cas. Mais l'écrasante majorité des refontes WordPress que je vois aujourd'hui font la même erreur. Elles superposent un page builder — Elementor, Divi, WPBakery — sur un thème complexe, et finissent par produire une interface d'édition que personne dans l'équipe marketing n'arrive à dompter sans une mini-formation.
Le résultat est presque toujours le même : la personne qui a configuré le site (souvent un freelance qui n'est plus là six mois plus tard) est la seule qui sait vraiment où cliquer pour faire ceci ou cela. L'équipe interne demande, attend, paie une demi-journée de TJM, ou — pire — renonce.
CMS headless : la rupture silencieuse
Depuis environ trois ans, une catégorie d'outils a transformé cette équation : les CMS headless modernes — Sanity, Strapi, Payload, Storyblok. L'idée fondamentale : séparer complètement l'interface d'édition (que les rédacteurs voient) du rendu front (que les visiteurs voient).
Cette séparation a deux conséquences pratiques. D'abord, l'interface d'édition est conçue pour les rédacteurs, pas comme un effet de bord d'un thème. Quand vous éditez un article dans Sanity, vous voyez des champs nommés en français, structurés, avec des contraintes claires. Pas un mur de modules entremêlés. Ensuite, le code front-end ne dépend plus de la structure d'édition, ce qui veut dire qu'on peut faire évoluer la maquette ou le design sans casser le contenu existant.

Le coût de cette approche, c'est qu'elle demande un peu plus de travail au moment du setup initial — il faut coder le rendu, configurer le schema, brancher l'API. Mais l'investissement se récupère typiquement en quelques semaines d'usage interne.
Le « test une minute »
Voici un test simple que je recommande à tout fondateur avant de signer un devis de refonte. Demandez à votre futur prestataire :
« Combien de temps faudra-t-il à une personne de mon équipe, sans connaissance technique, pour publier un nouvel article de blog ou modifier le texte d'une section de la home — du moment où elle ouvre l'admin jusqu'à la mise en ligne ? »
Si la réponse est floue, méfiez-vous. Si la réponse est « ça dépend » sans explication, méfiez-vous encore plus. Si la réponse est « 1 à 2 minutes pour un texte, 5 minutes pour un article complet avec image », vous êtes en face de quelqu'un qui a pensé au sujet.
Le bon prestataire aura aussi prévu une session de prise en main de 30 à 60 minutes, un manuel rédigé pour vous (pas un PDF de Sanity générique), et un canal de support pour les premières semaines.
Ce qu'on mesure chez Aureon dès l'audit
Quand on audite un site existant avant refonte, je mesure trois choses qui ne sont jamais dans le brief initial :
- Le temps moyen de publication d'un article — chronométrage live avec la personne qui le fait habituellement
- Le nombre de tâches éditoriales en backlog — combien de modifications attendent dans un Notion ou un Trello parce que c'est trop pénible
- Le sentiment d'autonomie de l'équipe — sur une échelle de 1 à 10, à quel point se sentent-ils libres de toucher au site
Ces trois indicateurs, juxtaposés au taux de conversion et au PageSpeed, donnent une photographie nettement plus honnête de ce que vaut votre site. Et ils définissent, plus que tout le reste, ce qu'il faut prioriser dans la refonte.

Trois questions à poser à votre prochain prestataire
Avant de signer, posez ces trois questions. Les réponses sont révélatrices.
D'abord : « Quelle techno CMS allez-vous utiliser et pourquoi celle-là spécifiquement pour mon cas ? » Méfiance si la réponse est « WordPress parce qu'on fait toujours du WordPress ».
Ensuite : « Pouvez-vous me montrer l'interface d'admin telle qu'elle sera, sur un site existant que vous avez livré ? » Si oui, demandez à voir comment se passe une modif simple. Si non, demandez pourquoi.
Enfin : « Que se passe-t-il dans six mois quand je veux ajouter un type de contenu auquel personne n'avait pensé — une nouvelle catégorie d'articles, un quiz, un calculateur ? » La bonne réponse implique une architecture modulaire, pas une refonte partielle.
Un site n'est pas un objet fini qu'on livre une fois. C'est un outil qu'on utilise tous les jours. Le KPI le plus important, c'est celui-là.

