Une refonte SaaS s’impose quand votre produit freine ceux qui l’utilisent, le vendent ou le développent. Cinq signes ne trompent pas : un support qui répond toujours aux mêmes questions, des démos qui demandent un mode d’emploi, des écrans qui s’alourdissent, des urgences noyées dans la masse et une équipe technique qui n’ose plus toucher au code. Si vous en reconnaissez deux ou plus, il est temps d’auditer avant de redessiner.
Un SaaS B2B ne casse pas du jour au lendemain. Il s’alourdit, fonctionnalité après fonctionnalité. Personne ne décide de le rendre compliqué, et pourtant c’est ce qui arrive. L’équipe qui le connaît par cœur ne voit plus les frictions ; les nouveaux utilisateurs, eux, les voient tout de suite.
Cet article détaille les cinq signaux, puis la façon de passer à l’action : choisir entre refonte complète et évolution progressive, auditer, migrer sans interrompre vos clients, prévoir les délais et choisir le bon partenaire.
Quels sont les 5 signes qu’une refonte SaaS s’impose ?
Aucun de ces signes ne suffit seul à justifier une refonte. Leur accumulation, en revanche, montre que le produit coûte plus qu’il ne rapporte à chaque nouvelle version. Pour chacun, nous indiquons ce qu’il révèle et comment le vérifier chez vous.
Les cinq signaux à surveiller, côté utilisateurs, ventes et technique.
1. Le support répond toujours aux mêmes questions
Si vos utilisateurs demandent sans cesse où se trouve une fonction, comment réaliser une action courante ou ce que signifie un statut, le problème ne vient pas d’eux. Il vient de l’interface. Chaque ticket de ce type est une friction que le produit aurait dû éviter.
Le Nielsen Norman Group parle de contacts qui n’existent que parce que le produit a échoué à servir l’utilisateur, et propose de suivre leur volume avant et après la refonte d’un parcours. C’est une mesure simple à présenter à une direction.
Pour le vérifier, classez trois mois de tickets par thème et par écran. Les questions qui reviennent dessinent la carte exacte des écrans à revoir. Interrogez aussi l’équipe support : elle sait quels écrans reviennent dans les appels, y compris ceux qui ne donnent jamais lieu à un ticket écrit.
2. Les démos commerciales demandent un mode d’emploi
Un produit B2B doit se comprendre en quelques minutes de démonstration. Si vos commerciaux passent la moitié du rendez-vous à expliquer comment naviguer, ou s’ils sautent certains écrans parce qu’ils sont trop chargés, le produit freine la vente.
Ce signal est souvent sous-estimé, car il se situe entre deux équipes. Le produit regarde l’usage, les ventes regardent la conversion, et personne ne relie les deux. Pourtant, un écran difficile à présenter est presque toujours un écran difficile à utiliser.
Demandez à deux commerciaux de vous montrer leur démo habituelle. Notez les écrans qu’ils évitent, les détours qu’ils prennent et les phrases du type « ne faites pas attention à ça ». Cette liste vaut un premier diagnostic.
3. Chaque nouvelle fonctionnalité alourdit les écrans
Des colonnes que personne ne lit, des actions en double, des filtres que seuls deux clients utilisent : la surcharge s’installe par petites touches. Chaque ajout se justifie seul, mais l’ensemble devient illisible.
Le réflexe est d’ajouter une fonctionnalité pour régler un problème. Le bon réflexe est souvent l’inverse : retirer ce qui ne sert pas, puis hiérarchiser ce qui reste.
4. Les situations importantes se perdent dans la masse
Quand tout est affiché au même niveau, rien ne ressort. Les utilisateurs doivent tout lire pour trouver ce qui demande leur attention, et finissent par rater l’essentiel : une échéance, un dossier bloqué, une anomalie.
C’est tout l’enjeu d’EPItrack Manager, un SaaS de gestion des équipements de protection individuelle pour les managers de site et les responsables HSE. Collaborateurs, dotations, stocks, contrôles et échéances : beaucoup d’informations, pour des utilisateurs qui doivent repérer vite ce qui n’est pas conforme.
EPItrack Manager : l’écran Collaborateurs conçu par Brutux Studio.
Le travail a porté sur l’architecture de l’information : l’écran est organisé autour des personnes, avec des statuts lisibles et une hiérarchie claire. Les situations non conformes ressortent au premier coup d’œil. C’est exactement ce qu’une refonte doit corriger quand l’écran existant met tout au même niveau.
5. Votre équipe technique hésite à toucher certaines parties
Quand l’interface s’est construite sans système commun, chaque écran a ses propres règles. Ajouter une fonctionnalité devient long et risqué, et la qualité visuelle varie d’une page à l’autre. Les développeurs finissent par contourner les zones fragiles.
Un design system, c’est-à-dire une bibliothèque de composants documentée, traite ce problème à la racine. Les mêmes boutons, tableaux et statuts partout : le produit gagne en cohérence pour vos utilisateurs, et vos équipes livrent plus vite. Notre page design UX/UI et design system détaille ce que contient un tel livrable.
Refonte complète ou évolution progressive : que choisir ?
Reste à choisir l’ampleur du chantier. Deux options s’affrontent : tout reconstruire puis basculer d’un coup, ou faire évoluer le produit par étapes. Le choix dépend de vos données, pas des goûts de l’équipe.
Ce que disent les données avant de trancher
Le Nielsen Norman Group recommande de procéder par changements incrémentaux et de ne passer à une refonte complète que si les données l’exigent. Il conseille aussi de mesurer l’effet d’un changement sur les utilisateurs avant de généraliser.
Le même institut nuance : l’accumulation de petites retouches finit par détruire la cohérence d’une interface, et appelle alors une nouvelle architecture. C’est exactement la situation des cinq signes : la cible doit être repensée, mais le passage vers elle peut rester progressif.
Trois questions aident à trancher :
- Le back-end est-il sain ? Si oui, la refonte peut porter sur l’interface en s’appuyant sur l’existant.
- Les frictions sont-elles concentrées ? Si quelques parcours concentrent les tickets, commencez par eux.
- Le modèle de données bloque-t-il un parcours prioritaire ? Seulement dans ce cas, une reprise technique plus profonde se justifie.
Pourquoi la bascule « big bang » coûte cher
La refonte « big bang » consiste à reconstruire en parallèle pendant des mois, puis à tout basculer en une fois. Sur le papier, c’est plus simple.
En pratique, vous maintenez deux produits, vous ne livrez rien aux clients pendant la reconstruction, et le jour de la bascule déroute des utilisateurs habitués.
Big bang ou migration par lots : le risque n’est pas réparti de la même façon.
Une réécriture complète est rarement nécessaire. Dans notre méthode de refonte de SaaS, quand le back-end tient, nous refaisons l’interface en nous appuyant dessus, et nous ne proposons de reprendre une zone technique fragile que lorsqu’elle bloque un parcours prioritaire.
Comment auditer un SaaS avant de le refondre ?
Une refonte qui commence par des maquettes commence par des opinions. L’audit remplace ces opinions par des faits : ce que font vraiment les utilisateurs, où ils bloquent, et ce que chaque correction rapporterait.
Croiser analytics, tickets et entretiens
Chaque source de données raconte une partie de l’histoire. Les analytics montrent ce qui se passe, sans dire pourquoi. Les tickets montrent ce qui bloque, mais seulement chez ceux qui prennent le temps d’écrire. Les entretiens expliquent le pourquoi, sur un petit nombre de personnes.
Croisées, elles se corrigent mutuellement. Un écran peu ouvert et absent des tickets n’a pas le même statut qu’un écran peu ouvert et très commenté.
Voici ce que nous relevons pour chaque parcours :
- les écrans les plus ouverts, et ceux que plus personne n’ouvre ;
- les étapes où les utilisateurs abandonnent ou reviennent en arrière ;
- les thèmes de tickets rattachés à chaque écran ;
- les contournements observés en entretien : exports vers un tableur, notes à côté, double saisie.
Ce dernier point est souvent le plus parlant. Un utilisateur qui exporte chaque semaine un tableau pour le retravailler ailleurs vous indique précisément ce que l’écran devrait faire.
Classer les chantiers par effort et par impact
L’audit produit une liste de frictions. Sans priorité, cette liste paralyse. Chaque chantier est donc classé selon l’effort qu’il demande et l’impact attendu pour les utilisateurs et pour l’entreprise.
| Effort | Impact | Décision |
|---|---|---|
| Faible | Fort | Quick win à livrer tout de suite |
| Élevé | Fort | Chantier de fond, à découper en lots |
| Faible | Faible | À grouper avec un autre lot |
| Élevé | Faible | À écarter pour l’instant |
Chez Brutux Studio, cet audit UX dure 2 à 3 semaines. Il se termine par un plan d’action priorisé et des quick wins maquettés, prêts pour vos développeurs, afin que les premières améliorations arrivent avant même le début de la refonte.
Comment migrer sans interrompre vos clients ?
Vos clients travaillent dans votre produit tous les jours. La refonte doit donc se faire pendant qu’ils l’utilisent, sans perte de données ni rupture de service. Deux chantiers avancent en parallèle : l’interface et la technique.
Côté interface : un design system de transition
Le design system ne se construit pas à la fin, une fois les écrans dessinés. Il se construit tôt, et il est pensé pour cohabiter avec l’existant : les nouveaux composants remplacent les anciens écran par écran, sans que le produit paraisse découpé en deux.
Le Nielsen Norman Group rappelle qu’un design system aide à gérer le design à grande échelle en réduisant la redondance, mais qu’il demande un entretien continu et n’est pas une solution ponctuelle. Prévoyez dès le départ qui le fera vivre après la refonte.
Les composants à traiter en premier sont ceux que l’on retrouve partout dans un SaaS B2B :
- les tableaux de données, avec tri, filtres et actions groupées ;
- les statuts et badges, qui doivent se lire sans légende ;
- les formulaires et leurs messages d’erreur ;
- les états vides, de chargement et d’erreur.
L’accessibilité se traite à ce moment-là, dans les composants, plutôt qu’en correction écran par écran. Les WCAG 2.2, recommandation du W3C publiée en octobre 2023, ajoutent par exemple des critères sur la taille minimale des cibles et sur le focus clavier qui ne doit pas être masqué.
Côté technique et données : remplacer pièce par pièce
Le schéma le plus sûr porte un nom : la « figue étrangleuse » (strangler fig). Microsoft le décrit comme une migration progressive d’un système existant, où une façade route chaque requête vers l’ancienne ou la nouvelle implémentation. Les utilisateurs gardent le même point d’entrée pendant toute la migration.
Concrètement, chaque lot suit le même chemin : le nouvel écran est construit, ouvert à quelques comptes, comparé à l’ancien, puis généralisé. L’ancien écran reste accessible tant que le nouveau n’a pas fait ses preuves, et un retour arrière reste possible à chaque étape.
Ce découpage rejoint les travaux du programme DORA de Google Cloud, pour qui le travail en petits lots est un principe essentiel dès que l’on veut apprendre vite de ses décisions. Une refonte en est le cas typique : chaque lot livré vous apprend quelque chose sur le suivant.
Reste la question des données. Pour concevoir et tester les nouveaux écrans, la CNIL recommande de travailler dans un environnement distinct de la production et d’utiliser autant que possible des jeux de données fictifs plutôt que des données personnelles réelles. Nous procédons ainsi, avec des données fictives ou anonymisées, et en respectant vos règles d’accès aux environnements.
Quels délais prévoir, et qui associer ?
Une refonte n’est pas un tunnel. Bien organisée, elle livre des améliorations visibles par vos utilisateurs bien avant d’être terminée. Le calendrier dépend surtout de la taille du produit et de l’état de son code.
Auditer, cibler, migrer, mesurer : une boucle qui se répète à chaque lot.
Un calendrier par cycles de 6 semaines
Chez Brutux Studio, une refonte démarre en général par l’audit produit de 2 à 3 semaines, puis se poursuit pendant 2 à 6 mois. Le travail est organisé en cycles de 6 semaines, et chaque cycle fait basculer un ensemble d’écrans vers la nouvelle interface.
Le déroulé suit quatre temps :
- Auditer : frictions, écrans délaissés et dette d’interface documentés, chantiers classés.
- Cibler : architecture de l’information revue, wireframes des parcours critiques, principes partagés avec vos équipes.
- Migrer : un lot d’écrans par cycle, avec mise en production fréquente.
- Mesurer : usage, tickets et retours clients suivis après chaque lot, pour choisir le périmètre suivant.
Ce rythme laisse aussi la place aux améliorations nouvelles. Une fois les écrans clarifiés, certaines tâches répétitives peuvent être confiées à l’IA, à condition de la placer au bon endroit : nous détaillons ce point dans notre article sur où l’IA crée vraiment de la valeur dans un SaaS B2B.
Accompagner les utilisateurs habitués
Le Nielsen Norman Group le constate : toute nouvelle interface suscite des plaintes, surtout chez les utilisateurs quotidiens, dont les gestes sont devenus automatiques. Ces réactions ne disent pas que la refonte est mauvaise. Elles disent qu’il faut l’accompagner.
Trois pratiques limitent ce choc :
- associer des clients dès l’audit, par des entretiens ;
- ouvrir les nouveaux écrans en avant-première à quelques comptes volontaires ;
- prévenir avant chaque bascule, en expliquant ce qui change et pourquoi.
Une migration par lots laisse en outre le temps de corriger avant de généraliser. Les repères qui comptent pour vos utilisateurs sont conservés, et les changements sont étendus seulement quand les premiers retours sont bons.
Comment choisir le partenaire de votre refonte SaaS ?
La refonte d’un produit en production engage votre relation client pendant plusieurs mois. Le choix du partenaire compte autant que la méthode. Quelques critères permettent de comparer les propositions sur le fond.
D’abord, la méthode de départ. Un partenaire sérieux commence par comprendre l’usage réel, avec des données et des utilisateurs, avant de montrer des maquettes. Méfiez-vous d’une proposition qui présente des écrans finis avant le moindre entretien.
Ensuite, la capacité à travailler avec vos développeurs. Une refonte se mène avec eux, pas à côté d’eux.
Sur une refonte, nous fournissons maquettes, composants et spécifications, nous participons aux revues de code et nous pouvons développer une partie du front avec votre équipe. Le savoir reste ainsi chez vous à la fin du projet.
Enfin, les livrables. Demandez ce que vous recevrez concrètement : fichiers de design organisés, design system documenté, plan de migration par lots, indicateurs de suivi. Un rapport sans maquettes ni priorités dort vite dans un dossier.
La proximité joue aussi, surtout pour les ateliers de cadrage et les tests utilisateurs. Depuis Thonon-les-Bains, nous rejoignons les équipes d’une agence SaaS à Genève, où les produits sont souvent multilingues et soumis à des circuits de validation stricts, comme celles d’une agence SaaS à Lausanne, de l’autre côté du lac.
Si votre produit présente deux ou plus des cinq signes décrits ici, n’attendez pas qu’un sixième apparaisse : réservez 30 minutes pour en parler, et repartez avec une première lecture de vos priorités.
Sources
- Nielsen Norman Group, Stop Reporting UX Activity and Report Business Outcomes : les contacts au support causés par un échec du produit, à mesurer avant et après une refonte.
- Nielsen Norman Group, Radical Redesign or Incremental Change? : privilégier les changements incrémentaux, sauf si les données exigent une refonte complète.
- Nielsen Norman Group, Fresh vs. Familiar: How Aggressively to Redesign : l’accumulation de retouches détruit la cohérence ; les plaintes après une nouvelle interface.
- Nielsen Norman Group, Design Systems 101 : définition et entretien continu d’un design system.
- W3C, What’s New in WCAG 2.2 : nouveaux critères d’accessibilité de la recommandation d’octobre 2023.
- Microsoft Learn, Strangler Fig pattern : migration progressive d’un système existant derrière une façade.
- DORA, Working in small batches : le travail en petits lots pour apprendre vite de ses décisions.
- CNIL, Sécurité : encadrer les développements informatiques : environnements distincts et jeux de données fictifs pour le développement et les tests.