Backoffice legacy : quand refondre, quand patcher, et comment trancher
Par Julien Brionne — Senior PM Freelance
Ton backoffice tient avec du scotch. Tout le monde le sait. Personne ne tranche. Voici comment décider entre refonte et itération — sans y laisser 6 mois.
Pour comprendre la posture d'intervention, voir Mon approche.
Ton backoffice a été construit il y a trois ans. Par un dev, un soir, pour débloquer un process urgent. Depuis, il a grossi. Des champs se sont ajoutés. Des workflows se sont greffés. Des règles métier vivent dans des if/else que personne ne comprend.
Aujourd’hui, les ops passent 40% de leur temps à contourner l’outil. Les PMs reçoivent un ticket “refonte backoffice” toutes les deux semaines. Et personne ne tranche. Parce que personne ne sait si c’est le bon moment pour refondre — ou si un patch suffit.
La question n'est pas technique. Elle est décisionnelle.
Le backoffice legacy n’est pas un problème technique. C’est un symptôme d’arbitrages non pris. La vraie question n’est jamais “faut-il refondre ?” mais “qu’est-ce que cet outil empêche de faire aujourd’hui, et combien ça coûte ?”. La réponse à cette question détermine si tu patches, si tu refonds, ou si tu vis avec.
Pourquoi le backoffice devient le sujet que personne ne tranche.
Le backoffice est un sujet ingrat. Il ne génère pas de revenu direct. Il n’a pas de sponsor naturel. Il vit entre le produit, l’engineering et les ops — et chacun considère que c’est le problème de l’autre.
Dans les scale-ups que j’ai traversées, le pattern est toujours le même. Le backoffice démarre comme un outil interne bricolé. Il fonctionne. Puis l’entreprise grandit. Les volumes augmentent. Les process se complexifient. L’outil ne suit plus. Mais comme il “marche encore”, personne ne prend la décision de le refaire.
Le coût réel est invisible. Il se cache dans le temps que les ops passent à copier-coller des données entre deux onglets. Dans les erreurs de saisie qui génèrent des tickets support. Dans les workarounds que chaque nouvel arrivant doit apprendre de son voisin parce que rien n’est documenté.
Comment savoir si c'est le moment de trancher.
Le coût de contournement dépasse le coût de refonte. Calcule le temps que tes équipes ops passent chaque semaine à contourner l’outil. Multiplie par le coût horaire. Si ce chiffre dépasse le coût estimé d’une refonte en 6 mois, la question est réglée. Chez Back Market, j’ai mesuré que les agents Care passaient 12 minutes par ticket à naviguer entre 4 écrans différents pour une action qui devrait prendre 2 minutes. Sur 800 tickets/jour, ça fait 130 heures/semaine de temps perdu.
L'outil bloque un changement de process. Tu veux automatiser un workflow. Tu veux changer une règle métier. Tu veux absorber un nouveau volume. Et à chaque fois, la réponse engineering est : “ça demande 3 semaines parce que le backoffice n’est pas prévu pour ça.” Quand l’outil empêche l’organisation d’évoluer, le patch ne suffit plus.
Le turnover ops augmente. Les gens partent parce que l’outil est pénible. Pas parce que le salaire est bas. Pas parce que le management est mauvais. Parce qu’ils passent leur journée à se battre contre un écran. C’est un signal faible que les Head of Ops remontent rarement — mais qui coûte cher en recrutement et en formation.
Un backoffice legacy n’est pas un problème technique. C’est une dette de décision qui se paie en temps humain.
Patcher ou refondre : le cadre de décision.
La refonte n’est pas toujours la bonne réponse. Le patch non plus. Le choix dépend de trois critères.
Le modèle de données est-il encore viable ? Si le modèle sous-jacent (les entités, les relations, les états) correspond encore à la réalité métier, tu patches. Tu améliores l’interface, tu ajoutes des raccourcis, tu automatises les actions répétitives. Si le modèle est dépassé — si les entités du backoffice ne correspondent plus à ce que font réellement les équipes — il faut refondre le modèle, pas l’écran.
Combien de process critiques dépendent de l'outil ? Si le backoffice sert 2-3 workflows bien identifiés, le patch est gérable. Si 15 process différents passent par le même outil avec des logiques incompatibles, le patch crée de la dette à chaque itération. Plus le nombre de process est élevé, plus la refonte a du sens — mais plus elle est risquée.
As-tu un owner produit dédié ? Une refonte de backoffice sans PM owner dédié échoue systématiquement. Ce n’est pas un side project. C’est un produit interne avec des utilisateurs, des contraintes, et des arbitrages à faire chaque semaine. Si tu n’as pas la bande passante produit pour porter la refonte, patche et revois la question dans 6 mois.
Comment mener une refonte sans y passer 6 mois.
La refonte big-bang est un piège. 6 mois de dev, 0 feedback terrain, et un outil livré qui ne colle pas à la réalité des ops. Voici l’approche que j’applique.
Shadow et cartographie.
Passe 2 jours à observer les ops utiliser l’outil. Pas en réunion. À côté d’eux. Note chaque clic inutile, chaque copier-coller, chaque onglet ouvert en parallèle. Identifie les 5 actions les plus fréquentes et mesure le temps réel de chacune.
Cartographie les workarounds. Chaque workaround est un besoin métier non couvert par l’outil. C’est ta roadmap de refonte.
MVP interne sur le workflow critique.
Choisis le workflow qui coûte le plus cher (en temps humain). Refonds uniquement celui-là. Livre un premier écran en 2 semaines. Mets-le en prod à côté de l’ancien outil. Mesure le delta de temps.
Ce premier quick win fait deux choses : il prouve la valeur de la refonte avec des chiffres, et il donne un point de comparaison pour prioriser les workflows suivants.
La console Care avait été construite en 2017. En 2021, les agents utilisaient 4 outils différents pour traiter un seul ticket. J’ai refondé la console par workflow, en commençant par le traitement des litiges (60% du volume). En 3 mois, le temps de traitement moyen a baissé de 35%.
Ce qui fait échouer les refontes.
Refondre l'interface sans toucher au process. Un bel écran sur un process cassé reste un process cassé. Avant de redesigner le backoffice, assure-toi que le workflow qu’il sert est le bon. Si le process lui-même est inefficace, refais le process d’abord.
Demander aux ops ce qu'ils veulent. Les ops décrivent des solutions, pas des problèmes. “Je veux un bouton pour exporter en CSV” cache un vrai besoin : “je dois croiser des données qui ne sont pas dans le même écran.” Observe le terrain. Ne te fie pas aux feature requests.
Lancer la refonte sans date de fin. Une refonte de backoffice sans deadline devient un chantier permanent. Fixe un scope. Fixe une date. Livre. Itère ensuite. Un backoffice imparfait mais livré vaut mieux qu’un backoffice parfait jamais terminé.
Tu vis ça ? Voir ce que je fais concrètement.
Le backoffice est le miroir de l'organisation.
Un backoffice legacy raconte l’histoire de toutes les décisions qui n’ont pas été prises. Chaque workaround est un arbitrage esquivé. La refonte n’est pas un projet technique. C’est un acte de clarification : décider ce que l’outil doit faire, ce qu’il ne doit plus faire, et qui en est responsable.