How to prepare your teams for a redesign (without internal chaos)

A redesign rarely starts with a team problem. It starts with a simple intention: improving the site, correcting what no longer works, passing a course.

Then, quite quickly, the subject changes.

Discussions no longer focus on pages or features, but on arbitrations. Who decides? What is the priority? How far to go? And above all: who will really make the site live once online?

This is often where complexity arises. Not because the project is not well thought out, but because it puts into tension topics that have remained implicit until then: roles, responsibilities, modes of collaboration.

Redesign acts as a revelation.

Essential in 30 seconds

A redesign does not derail because the solution is bad. It slips because the organization around is not ready.

When the rules of the game are not clear – who decides, who produces, who validates – the project advances... then slows down. Decisions come back, priorities move, and energy is dispersing.

Conversely, when these points are set early, everything becomes simpler: arbitrations are faster, teams are more autonomous, and the site has a real chance to exist after it is put online.

Redesign rarely fails for technical reasons

At first, everything seems fluid. The workshops are moving forward, the screens are taking shape, the teams are involved. We talk about user experience, design, sometimes performance.

Then, gradually, something changes. A validated decision returns to the table. A subject that was thought to be decided becomes open again. Backlog grows without really structure.

And with the approach to online publishing, a simple question comes up, often too late: who will manage the site on a daily basis? Who publishes? Who's valid? At what level of autonomy? On what content?

At that time, the project slowed down. Not because the technique blocks, but because the next was not actually thought out.

Classic mistakes and how to recognize them early

Some signals appear early, but often go unnoticed.

The first is when the redesign is approached as a design topic before being a business subject. Discussions revolve around pages, inspirations, interface. Everything is consistent... But no one clearly formulates what the site must produce: more leads, better qualify, shorten a sales cycle.

The result, a few months later, is quite classic: a more modern site, but difficult to drive. The contents exist, but they do not serve a clear mechanics.

Another frequent signal is that governance is based on simplicity.
"We decide together" works very well... until the moment when we have to decide. There, decisions stretch, meetings lengthen, and some topics come back several times without ever being really closed.

This is not a problem of competence. It's a framework problem.

There's also everything. as regards exploitation, often postponed to the end. As long as the site is not online, the question seems secondary. And yet, it is she who conditions everything: if publishing a page requires too much effort, too many validations, or too much technique, the site will not live.

Finally, there is the gap between teams. Marketing advances with its content and conversion issues. TIT, with its security, performance and integration constraints. Both are legitimate. But without explicit alignment, arbitrations come too late, and everyone feels like they are going through the decisions.

Pris séparément, ces points sont gérables. Ensemble, ils créent une inertie difficile à rattraper.

La méthode en 5 piliers pour préparer votre équipe

Préparer les équipes ne veut pas dire ajouter de la complexité ou produire plus de documentation.

C’est plutôt faire en sorte que certaines choses soient claires avant qu’elles ne deviennent des problèmes.

1. Clarifier la vision

D’abord, la direction. Pas une vision théorique, mais quelque chose d’utile pour décider. Quand un projet avance sans priorités explicites, tout devient important. Et quand tout est important, plus rien ne l’est vraiment. À l’inverse, quelques objectifs bien posés suffisent souvent à simplifier énormément les arbitrages.

2. Structurer la gouvernance

Ensuite, la décision. Beaucoup de projets ralentissent simplement parce que personne n’est légitime pour trancher rapidement. Clarifier qui décide, sur quels sujets, change immédiatement la dynamique. Ce n’est pas une question de hiérarchie, mais de responsabilité assumée.

3. Définir les rôles

Les rôles jouent le même rôle d’accélérateur — ou de frein. Tant que chacun “peut” produire, valider ou publier, tout dépend des personnes et des situations. Dès que ces rôles sont stabilisés, même de manière simple, les frictions diminuent fortement.

4. Anticiper l’exploitation

L’exploitation, elle, mérite d’être pensée tôt. Non pas en détail, mais dans ses grandes lignes : quels types de contenus seront produits, à quelle fréquence, avec quel niveau d’autonomie. Un site qui repose sur des cas particuliers permanents devient vite ingérable. Un site qui s’appuie sur quelques modèles clairs devient utilisable.

5. Accompagner le changement

Enfin, il y a l’adoption. Un nouvel outil, même bien conçu, ne s’impose pas. Sans un minimum d’accompagnement, les équipes contournent, reviennent à leurs habitudes, ou sollicitent en permanence les mêmes personnes. Quelques démonstrations, des exemples concrets, et un cadre simple suffisent souvent à éviter ça.

Rien de tout cela n’est complexe. Mais rien de tout cela ne se met en place tout seul !

Deux contextes, un même enjeu

Selon les organisations, la refonte ne pose pas exactement les mêmes défis.

Quand le marketing pilote seul, l’enjeu principal est l’autonomie. Produire, publier, tester sans dépendre de la technique. La tentation est alors de vouloir trop de flexibilité, au risque de rendre l’outil difficile à utiliser.

Quand l’IT est fortement impliquée, d’autres contraintes entrent en jeu : sécurité, performance, intégration au SI. Les arbitrages sont plus structurants, mais aussi plus sensibles.

Dans les deux cas, le point clé reste le même : rendre explicite qui décide, et sur quels sujets.

C’est ce qui évite que les tensions se déplacent dans le projet.

“Est-ce qu’on est prêts ?” Un diagnostic rapide

Certains indices sont assez fiables.

Quand les objectifs du site sont difficiles à formuler simplement, les décisions le seront aussi.
Quand les arbitrages nécessitent systématiquement du consensus, ils prendront du temps.
Quand personne ne sait vraiment qui publiera dans quelques mois, l’adoption sera fragile.

À l’inverse, quand ces points sont clairs – même de manière imparfaite – le projet devient beaucoup plus lisible.

Et souvent, plus rapide.

Ce que ça change, concrètement

La différence n’est pas spectaculaire au départ.

Les ateliers restent les mêmes. Les livrables aussi. Rien ne semble radicalement différent.

Mais progressivement, les écarts apparaissent.

D’un côté, des projets où les décisions s’étirent, où les équipes s’ajustent en permanence, où la mise en ligne marque presque la fin du sujet.

De l’autre, des projets où les arbitrages sont plus simples, où les équipes savent quoi faire, et où le site commence réellement à vivre une fois publié.

Ce n’est pas une question de méthode miracle.
C’est une question de clarté.

Quand se faire aider

Il n’est pas toujours nécessaire d’en faire plus. Souvent, le vrai besoin est de rendre explicite ce qui ne l’est pas encore : qui décide, comment les équipes travaillent ensemble, ce qui est réellement prioritaire.

Un regard externe peut aider à ça. Pas pour complexifier, mais pour structurer. Mettre des mots sur des zones floues, poser un cadre lisible, et éviter que certains sujets critiques apparaissent trop tard.

Une refonte reste un projet technique. Mais sa réussite, elle, est presque toujours organisationnelle.

Si vous êtes dans cette phase de clarification, vous pouvez aussi mettre à plat votre situation avec nous, simplement pour y voir plus clair.