Refonte Tech : le guide ultra-concret

Les déclencheurs légitimes 5 facteurs qui justifient une refonte : Le temps et le cout de mise en place de nouvelles fonctionnalités augmentent de sprint en sprint. L'architecture actuelle ne répond plus aux enjeux business. L'entreprise évolue, le système technique ne suit plus.

Les technologies sont obsolètes. Le recrutement devient difficile, la capacité d'évolution du produit ralentit. L'accumulation de bugs et la dégradation des performances.

Les équipes passent plus de temps à corriger qu'à innover. La sécurité est compromise. Les systèmes obsolètes sont plus vulnérables aux attaques.

Ce qui n'est PAS un déclencheur 3 fausses bonnes raisons : Le ratio impact/cout est trop faible. Retour sur investissement incertain ou projet trop risqué. Le plaisir d'utiliser les dernières technologies à la mode.

Une refonte doit répondre à des besoins business concrets. L'équipe n'est pas disponible ou pas techniquement prête. Une refonte est un projet long et complexe.

Les objectifs possibles d'une refonte : Modernisation de la stack technique. Stack trop ancienne = frein au recrutement et à l'innovation. Amélioration du code.

Le rendre plus lisible, plus modulaire, réduire les anomalies en production. Perte de connaissance de l'existant. Repartir sur des bases saines avec une documentation à jour.

Qui sont les décideurs : Les C-Levels et le CODIR. Vision stratégique globale, alignement des investissements avec les objectifs business. Le CTO évalue la pertinence technique.

Le CEO et les autres C-Levels valident la valeur ajoutée. L'équipe de développement. Compréhension claire des limites du système.

Capacité à anticiper les besoins futurs. Le cri d'alarme vient souvent d'eux. Les équipes commerciales et marketing.

Leur retour mesure les besoins et les attentes du marché. Les arguments pour convaincre 4 leviers : Le cout d'ajout d'une fonctionnalité augmente. Chaque feature prend plus de temps et coute plus cher.

Les anomalies de production augmentent. L'équipe produit moins de valeur ajoutée. La question du risque existentiel.

Que perd l'entreprise si le système actuel tombe en panne ? Repartir sur des bases saines. Diffuser la connaissance, améliorer la sécurité, moderniser la stack.

Refonte Big Bang L'ensemble du système est remplacé en une seule fois par une nouvelle architecture. Caractéristiques : Changement radical. Tout est remplacé d'un coup, les anciens composants sont retirés.

Risque élevé. En cas de problème, retour en arrière difficile. Longue préparation.

Développement, tests et validation avant basculement. Interruption de service nécessaire pour la migration. Cout initial élevé.

Investissements lourds avant que les bénéfices soient visibles. Difficultés à prévoir tous les scénarios. Bugs et incompatibilités possibles après déploiement.

Avantage : si bien exécuté, bénéfices immédiats. Nouvelle architecture, nouvelles fonctionnalités, gains de performance. Migration progressive (fil de l'eau) Le système est transformé par étapes.

L'ancien et le nouveau coexistent. Caractéristiques : Changement progressif. Modules migrés un par un, le reste du système reste intact.

Livraison de valeur continue. Nouvelles fonctionnalités en parallèle de la réécriture. Moins de risque.

Correction facile des problèmes sans impacter tous les utilisateurs. Coexistence des systèmes. Test de la nouvelle architecture sans interruption majeure.

Impact limité sur les utilisateurs. Le service existant continue de fonctionner. Planification flexible.

Migration étalée, priorisation des parties critiques en premier. Tests et validation continus à chaque étape. Cout étalé dans le temps.

Meilleur controle budgétaire. Complexité d'intégration. Passerelles temporaires entre l'ancien et le nouveau système.

éléments à clarifier : Le contexte du projet. Évaluer le calendrier et accepter qu'il puisse s'étendre. Planification réaliste pour éviter que la refonte ne devienne un gouffre.

La connaissance du système existant. Cartographier les dépendances, évaluer les points critiques, avoir une vision claire de la cible en termes de fonctionnalités, d'architecture et de technologies. L'expertise de l'équipe.

Compréhension de l'ancien système, maîtrise des nouvelles technologies, capacité à gérer la cohabitation ancien/nouveau code. La composition de l'équipe. Équipe compétente et motivée.

Renforcement possible avec des experts ou consultants expérimentés. Facteurs de réussite : L'expérience. Une équipe avec une expérience préalable anticipe les défis et gère les imprévus.

La satisfaction des utilisateurs finaux et des équipes internes. L'organisation et la méthodologie. Le projet doit être porté par tout le monde, de la direction aux développeurs.

Une communication constante, claire et transparente. Une compréhension claire des objectifs par chaque membre de l'équipe. Frustrations courantes : Organisation et méthodologie.

Manque d'engagement, communication insuffisante. Le sentiment de ne pas ajouter de valeur à court terme. Difficile de montrer des résultats immédiats.

La difficulté de voir l'avenir. Incertitude sur les délais et les résultats. Des choix techniques pris trop rapidement au début du projet.

indicateurs de mesure : Réduction du temps consacré aux bugs. Moins de support client, plus de temps pour les taches à forte valeur ajoutée. Satisfaction des développeurs.

Un projet modernisé réduit la frustration, renforce la motivation et la productivité. Capacité à développer de nouvelles fonctionnalités. Production plus rapide et plus grande agilité.

Respect du budget. Rester dans les limites définies témoigne d'une gestion efficace. Capacité à recruter sur la nouvelle stack.

Si cela faisait partie des objectifs initiaux. Important : Définir des OKR spécifiques au contexte et au projet pour suivre les progrès. Exemples : performances, satisfaction utilisateurs, stabilité du système.

Contributeur : Benjamin Lassus, VP Engineering. Les 6 problèmes identifiés : Stabilité de la plateforme et dette technique accumulée sur 7 ans. Monolithe distribué, complexité business, beaucoup de flux et de features.

"Après 7 ans on a accumulé beaucoup de dette, le système était instable à opérer. On avait ce qu'on appelle un monolithe distribué qui a une grosse lourdeur et une complexité business car il y a beaucoup de flux dans tous les sens et beaucoup de features."

Gros départ de plusieurs personnes dans l'équipe. Perte de savoir et de documentation. Infrastructure trop chère (+60k euros mensuel).

Stack pas homogène. Beaucoup de langages accumulés et pas maitrisés en interne. Trop de tests manuels.

Trop chronophage. Serveur SQL critique, RabbitMQ surchargé. La vision 5 axes stratégiques : Enjeux financiers.

Calendrier serré pour réduire les coûts d'exploitation. Équipe réduite. Focus sur les développements à forte valeur ajoutée, automatiser les taches chronophages.

Moderniser tout le système. Stack technique, infrastructure, stack data. Couplage plateforme SaaS.

Externaliser les fonctions à faible valeur ajoutée, variabiliser les coûts. Principes directeurs. Système agnostique, simplicité, factorisation, rationalisation, documentation.

Lancer la transformation Étape 1, Étude Produit : "On démarre par une étude produit, car au-delà de la stack on a accumulé beaucoup de features et d'outils car la technologie s'est développée en interne pour les clients et pour les collaborateurs." Benjamin Lassus.

phases : Audit interne. Interviews, sondage des équipes sur leurs besoins. Définition du MVP.

Définir les briques MVP. Priorisation dans le temps de chaque brique. Choisir le futur partenaire SaaS.

Gap Analysis (3 à 6 mois), cahier des charges, analyse financière. Périmètre fonctionnel. Découpage entre développement interne et externalisation.

Étape 2, Transformer l'organisation : "Avant de construire le nouveau système on s'est attachés à changer l'organisation. Pour nous, c'était impensable de garder l'organisation actuelle pour atteindre ce nouveau produit." Benjamin Lassus. Transformation selon la Loi de Conway : FT Legacy : la prod tourne et doit être maintenue.

FT Platform : socle technique (middleware et infra) au service des équipes fonctionnelles. Stream User Journey : périmètre utilisateur. Stream Excellence Ops : périmètre opérationnel.

Résultats : définition du sizing des équipes, renforts externes, alignement sur les enjeux, première roadmap. Étape 3, Transformer la stack technique : Conception event-based (RabbitMQ). Communication scooter décorrélée du business.

Transition avec le Legacy. Rollback possible, déploiement ciblé, refonte mobile progressive. Stack homogène.

.NET7 & React (Web/Native). Réutilisation et standardisation. Bonnes pratiques.

Code first, tests unitaires, tests intégration, conventional commit, QA automatisée. Étape 4, Transformer l'infra : Avant : +7 ans d'infra, hybride Cloud/OVH, équipe réduite, peu de documentation, risques business élevés. Après : infra from scratch sur nouveau compte AWS, zéro tache manuelle (Terraform/Ansible), culture FinOps (-20k euros/mois), expertise AWS (CloudWatch, ElasticCache, RDS, EKS).

Résultats et impact Difficultés : Legacy (2 infras à payer, produit qui n'évolue pas). Manque de Leads pour encadrer les équipes. Maintenir l'alignement sur un objectif long terme et exigeant.

Curseur entre qualité de code et efficience. Succès : Pas de régression. Amélioration du produit et migration transparente.

Maitrise de la stack (savoir, pratiques). Challenge technique très riche pour l'équipe. Les 7 clés à retenir : Tech for product.

Attention à la Tech pour la Tech. Attention au moral des équipes sur la durée. Sur-communiquer et donner du sens.

Infuser les bonnes pratiques et les incarner en accompagnant les équipes. Estimation macro et bonne méthodologie. Capitaliser sur les forces de l'équipe.

Transformer l'organisation et les process (Loi de Conway). Etre transparent sur les coûts.

Contributeur : Mickael Wegerich, Tech Lead Node & React. Contexte : Refonte backend d'une application B2B de gestion de planning. Deux équipes front et back, projet fonctionnel sans anomalie majeure.

Élément déclencheur : 2 ans après le lancement, réunification des deux équipes. Le métier demande une fonctionnalité impossible à implémenter avec le code actuel. Constat : en l'état, on ne peut pas implémenter la fonctionnalité demandée.

La refonte est lancée. Lancement et relation client : "Le projet rapporte de l'argent à l'entreprise, ce n'est pas un side project. On ne voulait pas vendre une refonte Big Bang, ça fait peur et par expérience, ça ne fonctionne jamais." Mickael Wegerich, Tech Lead Node & React.

Principe : tout refaire petit à petit, en continuant à livrer de nouvelles fonctionnalités et corrections de bugs. Relation client : Etre transparent. Décisions, problèmes.

Montrer que ça avance. Mise en production plusieurs fois par semaine. Avoir l'autonomie.

L'équipe gère ses priorités. Équipe et pratiques : Composition : 1 PO, 1 QA, 4 à 6 devs (1 Tech Lead, 1 sénior, 2 confirmés, 1 à 2 juniors). Stack OPS : AWS, Kubernetes, Helm, ArgoCD, Prometheus, Grafana, Loki, RabbitMQ.

Dépendances externes : Auth0, Business API, équipe mobile, autre gestionnaire de planning. Stratégie : Strangler Fig Pattern. Remplacer incrémentalement l'ancien par le nouveau pour étouffer le Legacy.

Pratiques : DevOps, intégration continue, Mob/Pair programming, NoEstimate, règles métiers validées à la source, communication étroite (Discord), recette Lean. Cohabitation : Nouvelle version d'API (v5 vers v6), nouveau dépot de code, nouvelle(s) base(s) de données.

L'API v5 Legacy n'est pas touchée. Suivi du décommissionnement en 6 états : pas encore fait, en cours, fait mais pas en prod, fait mais pas utilisé en prod, utilisé en prod, complètement décommissionné. Résultats : Période : 01/07/2020 au 31/12/2022 (640 jours ouvrés).

Chiffres fonctionnels : ~1250 établissements clients. ~15 000 commandes saisies par mois. ~10 000 utilisateurs uniques quotidiens.

Chiffres techniques : ~50 endpoints. 161 mises en production, soit 1,2 par semaine. ~5 jours en moyenne pour mettre un ticket en production.

Conclusions : Pas d'estimation formelle. Peu ou pas de bugs. Approche incrémentale.

Pas d'anticipation excessive des problèmes. Outillage et monitoring solides. Le code refait est toujours utilisé 2,5 ans après.

Plus d'API Legacy. Plus de 2 ans pour le back seul (front à refaire ensuite). "Lors de la conception d'une nouvelle application, nous devons tout faire pour faciliter son futur remplacement, afin qu'il puisse se faire de manière élégante.

Tout ce que nous faisons, c'est écrire aujourd'hui le logiciel hérité de demain." Martin Fowler