Refondre ou mieux maintenir ?

À l’occasion d’une visite terrain, j’ai éprouvé un sentiment de déjà vu : une énième tentative échouée de refonte d’une plateforme informatique. Autrement dit, un projet au budget conséquent, fondé sur de grands espoirs, qui se termine en grand dérapage.

L’histoire commence toujours de la même façon. Les équipes ne parviennent plus à livrer, empêtrées dans un système vétuste qu’elles ne maîtrisent plus. Les bugs et les plaintes des clients se multiplient, les ventes stagnent. Dès que les choses ne fonctionnent plus comme prévu, on pense qu’une remise à zéro viendra tout résoudre. Vraiment ?

Le schéma de pensée classique qui aboutit à ces dérapages est bien souvent celui des 4D : un petit groupe de dirigeants (ou un seul individu situé au sommet de la pyramide) définit rapidement le problème en fonction de sa propre interprétation de la situation, décide de la solution, dirige les équipes pour qu’elles exécutent la solution, puis démêle les imprévus et les échecs après coup. Dans le cas d’une refonte d’un site ou d’une plateforme, le schéma se décompose comme ceci :

● Définir : la direction perçoit le problème comme un besoin urgent de modernisation pour rester compétitif. Entre bugs de la plateforme et baisse des ventes, la meilleure solution envisagée est une refonte totale pour intégrer des technologies avancées comme l’IA et se différencier sur le marché. C’est à priori une belle opportunité de retrouver de l’agilité, et c’est aussi une réponse donnée aux développeurs qui se plaignent tous les jours des difficultés qu’ils rencontrent avec la base de code existante.

● Décider : un budget conséquent est alloué à ce projet de refonte, et le directeur produit, déjà submergé par d’autres priorités, est pressé de fournir un plan détaillé pour le mener à bien. La coordination avec le directeur informatique et les leaders des autres métiers est difficile et retarde la prise de décision – et pendant ce temps, la situation continue de se dégrader.

● Diriger : le CEO exige alors des suivis réguliers sur l’avancement du projet, par des équipes qui sont déjà surchargées par le support et la correction des bugs suite aux nombreuses plaintes des clients. Elles sont en permanence tiraillées entre le travail sur le système existant et la refonte en cours.

● Démêler : au fil du temps, des difficultés surgissent : des règles métier qui avaient été oubliées, de nouvelles fonctionnalités demandées en cours de route. Des retards et des dépassements de budget apparaissent, les équipes sont démotivées et les managers doivent gérer ces nouvelles difficultés en plus des plaintes croissantes des clients. Pour finir au plus vite, les équipes en viennent à prendre des raccourcis sur la qualité, ce qui fait qu’au moment de sortir, le système flambant neuf est déjà dégradé. Pendant ce temps, le marché évolue, laissant l’entreprise derrière ses concurrents.

Le même schéma se reproduit encore et encore dans nos entreprises alors même qu’on connait pourtant depuis longtemps les risques d’une telle aventure. C’est ainsi par exemple qu’aux débuts d’internet, à la fin des années 90, le navigateur Netscape s’était fait distancer par Internet Explorer – un retard qu’ils n’ont jamais pu rattraper.

Ce que l’on voit dans ce schéma, ce sont les conséquences de la qualité de la décision prise en amont. Le modèle 4D conduit souvent à des décisions dangereuses, parce qu’elles sont prises avec peu d’informations, sur la base de croyances et d’expériences personnelles qui forment une image fausse de la réalité. Et cette décision est au final rarement considérée comme absurde ou à l’origine des problèmes rencontrés car les conséquences négatives arrivent bien longtemps après que la décision a été prise, et parce que ces conséquences peuvent, en plus, être facilement attribuées à ceux qui ont mis en œuvre le plan d’action, plutôt qu’à ceux qui ont pris la décision.
Dans le cas de la refonte, en quoi le raisonnement est-il erroné ?

La vétusté et la dégradation d’un système, ce que l’on appelle la “dette technique”, n’arrive pas d’un coup : les équipes s’y embourbent changement après changement, au fil du temps. Malgré le fait qu’elles se plaignent de ne jamais avoir le temps de faire les choses correctement, on leur demande pourtant sans cesse d’accélérer pour produire de plus en plus de fonctionnalités. Pire, cette dégradation est vue comme une fatalité : “Des systèmes informatiques sans bugs, ça n’est pas possible”. La vision business est qu’il vaut mieux sortir des produits rapidement, même avec des bugs, car cela rapporte plus, et plus vite. Et quand cela ne rapportera plus, la refonte technique sera là pour nous sauver – même si, on le sait, les refontes sont souvent des gouffres financiers.

Mais en réalité, la refonte est un prétexte pour ne pas mettre les ressources au bon endroit, c’est-à-dire investir dans la qualité (built-in quality) et la maintenance au quotidien. Une bonne refonte, c’est en fait une somme de mini-refontes en continu qui évitent LA refonte.

Quelle pourrait être la façon de prendre de meilleures décisions dans ce type de cas de figure ? Cela commence par réaliser que prendre des décisions, c’est une pratique. On s’y entraîne de manière délibérée, en s’appuyant sur le modèle des 4C : on va chercher les vrais problèmes sur le terrain, au contact des clients et des équipes, pour découvrir ce que l’on ignore de la situation. Ensuite on se confronte à ces défis, ce qui nous amène à remettre en question les solutions qu’on a en tête. Pour bien orienter tout le monde dans la bonne direction, on cadre ensuite les objectifs de manière claire, ce qui a pour mérite de mobiliser les équipes pour la phase suivante. Enfin, on co-construit des solutions avec les gens du terrain, et chaque contribution enrichit la solution globale.
Pour l’illustrer, prenons l’exemple d’une plateforme digitale de marketplace, conçue pour permettre aux clients de commander des produits en ligne :

● Chercher : la CEO fait des visites régulières sur le terrain avec ses managers, dans les différents services de l’entreprise. Elle observe directement plusieurs problèmes : des plaintes récurrentes de clients concernant des retards et des erreurs de colis au Service Client, des camions à moitié vides posant des défis logistiques, et des équipes informatiques freinées par une dette technique significative dans des portions spécifiques du système. Ces visites révèlent des défis opérationnels ignorés lors des discussions initiales sur la refonte.

● Confronter : après avoir partagé ces observations avec son équipe de direction, elle fait émerger un consensus sur les véritables problèmes à résoudre : mieux synchroniser les entrepôts avec la logistique et optimiser le remplissage des camions de livraison. La dette technique, bien que sérieuse, n’est pas la principale cause des plaintes des clients à ce jour. Toutefois, désireuse de comprendre ce problème en profondeur, la CEO initie une démarche de recherche approfondie en demandant à l’équipe de faire une analyse fonctionnelle du système et de mettre en évidence les points forts et les points faibles. Le but est de décomposer le problème et de mobiliser les équipes pour trouver des solutions plus ciblées et durables qu’une refonte globale.

● Cadrer : une nouvelle orientation est définie : « Le bon colis livré dans les temps. » Ce cadre clair permet à chaque personne de l’entreprise de comprendre comment contribuer efficacement à l’atteinte de l’objectif.

● Co-construire : les équipes collaborent pour développer des améliorations locales qui optimisent les délais de livraison et réduisent les erreurs. Ces initiatives spécifiques s’assemblent pour créer une solution cohérente et complète, permettant de résoudre l’enjeu à grande échelle.
Le modèle 4C est une pratique : il ne s’utilise pas seulement lorsqu’une décision urgente se présente, mais comme une démarche régulière pour enrichir son champ de connaissances et ne pas juste se reposer sur son répertoire de solutions connues.

En définitive, être décideur, c’est moins un rôle qu’un savoir-faire. Comment améliorez vous la qualité de vos propres décisions ? Dans votre propre contexte, maintenant, quel est l’élément que vous envisagez de remplacer ? Que faudrait-il aller voir en premier ?

Sandrine Olivencia