Repurchase dans le cadre des 6R : quand substituer plutôt que migrer
Le repurchase est l'une des six stratégies clés du framework AWS 6R pour le choix de modèles de transformation cloud. Contrairement aux autres approches (rehost, replatform, refactor, retire, retain) qui concernent la gestion ou la refonte technique du logiciel existant, le repurchase consiste à abandonner complètement l'application on-premise actuelle et à la remplacer par une solution SaaS ou un service managé AWS natif. Cette stratégie est particulièrement pertinente pour les applications métier généralistes, les ERP, les CRM ou les outils collaboratifs qui existent déjà en version cloud moderne. Plutôt que d'investir des ressources d'ingénierie pour migrer ou refondre du code legacy, on substitue le logiciel lui-même. C'est une décision stratégique qui sort du périmètre purement technique : elle répond à une question business fondamentale : combien coûte-t-il de garder ce que nous avons, plutôt que de basculer sur quelque chose de neuf qui existe déjà ? Le repurchase représente donc une rupture avec le patrimoine logiciel existant, assumée et planifiée, en échange d'une solution standard qui limite la spécialisation technique et la dette d'infrastructure.
Analyser le TCO : coûts visibles et cachés du logiciel legacy vs. SaaS
Avant de décider un repurchase, il faut d'abord mesurer le coût total de possession (TCO) du logiciel legacy actuel. Ce calcul inclut bien plus que le tarif d'une licence annuelle. D'un côté, le logiciel on-premise génère des coûts d'infrastructure (serveurs physiques ou virtuels, maintenance hardware, électricité, refroidissement, sauvegardes, plans de continuité), des coûts de main-d'œuvre interne (administrateurs système, développeurs mainteneurs, support utilisateurs spécialisés), des coûts cachés liés à la dette technique (bugs complexes à corriger, dépendances obsolètes, difficultés à recruter des experts sur des techtos anciennes), et enfin les coûts de sécurité et conformité (patchs critiques, audits, mises à jour de sécurité, données sensibles hébergées on-premise). Le SaaS, lui, présente un TCO généralement composé d'un tarif par utilisateur ou par transaction (bien visible et prévisible), d'une faible charge IT pour l'administration (l'éditeur gère la sécurité, les mises à jour, la disponibilité), et de coûts d'intégration (onboarding, migration des données, formation) qui sont ponctuels. Pour comparer honnêtement, il faut valoriser chaque catégorie de coûts sur la même période (habituellement 3 à 5 ans). Un logiciel legacy qui emploie deux personnes à plein temps pour sa maintenance, hébergé sur du hardware qu'il faut renouveler tous les trois ans, représente souvent un TCO bien supérieur à un SaaS coûtant 50 ou 100 euros par utilisateur et par mois. Les entreprises sont régulièrement surprises par cette comparaison, car les coûts directs du legacy sont éparpillés entre plusieurs budgets (IT, HR, infrastructure) tandis que le SaaS apparaît comme une ligne unique de dépense.
Quand le repurchase prime sur les autres 6R : critères et signaux d'alerte
Le repurchase n'est pas toujours la meilleure option. Certains signaux doivent alerter le DSI que cette stratégie est pertinente plutôt que de dépenser des mois et des budgets considérables en migration technique. Premièrement, si l'application legacy résout un besoin métier GÉNÉRIQUE : paie, compta, CRM, gestion de projet, e-commerce, collaboration d'équipe. Un SaaS existant sur le marché couvre probablement 80 à 95 pour cent du besoin, et l'écart peut souvent être absorbé par des intégrations standards (API, webhooks) ou des configurations mineures. Deuxièmement, si le code legacy est ancien, peu documenté et peu attractif pour l'équipe interne : peu de développeurs veulent maintenir du code Perl, du VB6, du Delphi. Les coûts de rétention et de recrutement explosent, et vous partez d'une position faible sur le marché du travail. Troisièmement, si vous n'avez pas de compétence interne en cloud (AWS, Kubernetes, architectures cloud natives) : la migration technique demandera du ramp-up, ou l'appel à un prestataire externe coûteux et long. Le repurchase élimine cette barrière de compétence. Quatrièmement, si votre application legacy tourne sur une infrastructure propriétaire ou coûteuse (mainframe, bases de données très spécialisées, technologies mortes) : la migration vers AWS sur ces technologies est complexe, alors qu'un SaaS cloud-natif vous sort complètement de cette ornière. Enfin, si l'innovation métier dépend plus de l'accès à de nouvelles capacités (IA, analytics en temps réel, mobilité) que de la maîtrise du code : un SaaS moderne reçoit ces capacités automatiquement via les mises à jour de l'éditeur, tandis qu'une application legacy en version ancienne vous enferme.
Les pièges courants du repurchase et comment les éviter
Le repurchase paraît simple en théorie, mais il porte des risques concrets. Le premier piège est la sous-estimation de la complexité fonctionnelle du legacy. Une application en production depuis 10 ans accumule souvent des extensions, des règles métier complexes, des intégrations manuelles ou des workflows que personne ne documente car ils sont « évidents » pour les utilisateurs historiques. Quand vous testez le SaaS sur quelques cas nominaux, il semble parfait. Mais lors de la migration réelle, vous découvrez des centaines de micro-cas d'usage non couverts. Pour l'éviter, faut-il faire un audit fonctionnel complet du legacy AVANT de signer le SaaS : liste des écrans, des reports, des paramètres, des intégrations. Comparez chaque point avec le SaaS. Acceptez que 20 pour cent des besoins ne seront plus automatisés et demanderont un workaround ou un contournement. Le deuxième piège est le coût caché de migration des données. Passer de bases legacy aux nouvelles structures du SaaS est rarement un simple export-import. Les formats diffèrent, les règles de validation change, les références croisées deviennent invalides. Un trop grand nombre d'entreprises accepte un repurchase sur le TCO théorique, puis dépense trois à quatre fois le budget annuel du logiciel juste pour nettoyer et migrer les données. Prévoyez cette charge comme une variable à évaluer indépendamment de la licence. Le troisième piège est l'oubli des dépendances : votre legacy n'existe pas isolé. Il échange probablement des données avec d'autres systèmes (paie, compta, warehouse). Un SaaS propriétaire peut avoir des API, mais elles sont limitées ou payantes. Les intégrations peuvent prendre deux à trois fois plus de temps que la mise en service du SaaS lui-même. Le quatrième piège est de croire que le repurchase réduit la charge IT. Pendant plusieurs mois après le basculement, les utilisateurs signalent des anomalies, des demandes d'ajustement. Vous avez moins de charge « maintenance technique du logiciel » mais plus de charge « support utilisateurs et exceptions ». Planifiez du personnel dédié pendant six mois après go-live.
Feuille de route de décision : évaluer le repurchase étape par étape
Prendre une décision de repurchase ne peut pas être un réflexe : elle doit s'appuyer sur une feuille de route structurée. Étape 1 : définir clairement le besoin métier couvert par le legacy. Ne pas dire « notre CRM », mais « gestion des prospects, pipeline de vente, forecasting, rapports mensuels, intégration avec mailchimp ». Étape 2 : faire un audit rapide du legacy, en parlant à trois à cinq utilisateurs clés et à l'équipe IT. Lister les douleurs actuelles (lenteur, bugs, maintenance coûteuse, limitation de croissance) et les points forts (customisations complexes, intégrations spécifiques, données archivées depuis 20 ans). Étape 3 : identifier deux à trois candidats SaaS crédibles sur le marché. Ne pas en retenir juste un : les éditeurs marketing sont souvent trop optimistes sur ce qu'ils peuvent faire. Étape 4 : pour chaque SaaS, obtenir une licence d'essai et charger un utilisateur power-user du legacy de le tester sur ses cas d'usage quotidiens pendant une semaine. Pas une démo avec les consultants de l'éditeur, mais un vrai test. Étape 5 : analyser les écarts. Pour chaque besoin du legacy non couvert par le SaaS, estimer le coût du workaround (manuel, intégration, configuration) ou la limite acceptable de non-couverture. Étape 6 : comparer le TCO du legacy sur 3 à 5 ans avec le TCO du SaaS (coûts de licence, intégration, formation, support interne, éventuels workarounds). Ajouter un buffer de 20 à 30 pour cent pour les imprévus. Étape 7 : si le SaaS gagne, valider sa viabilité à long terme : santé financière de l'éditeur, trajectoire de prix, support géographique, certifications de sécurité et conformité que vous exigez (RGPD, SOC 2, ISO 27001). Étape 8 : définir un plan de migration minimal : quelle est la date limite du legacy, quels utilisateurs basculent en premier, comment gérez-vous les données historiques. Cette feuille de route prend quatre à six semaines et coûte bien moins cher qu'une mauvaise décision prise rapidement.
Intégration du repurchase dans le plan de migration global AWS
Le repurchase n'existe pas en isolation. Vous avez probablement un portefeuille d'applications à migrer vers AWS, et certaines seront en repurchase, d'autres en rehost, d'autres en refactor. Le repurchase doit s'inscrire dans une stratégie cohérente. Premièrement, priorisez les repurchase en premier dans votre migration AWS, avant les migrations techniques lourdes. Pourquoi ? Parce qu'elles dégagent rapidement des ressources IT internes (vous arrêtez de maintenir un logiciel), libèrent du budget IT (vous payez un SaaS au lieu de l'infrastructure on-premise) et donnent des gains visibles à l'organisation en trois à six mois. Cela crée du momentum et de la crédibilité pour le projet de migration global. Deuxièmement, acceptez que le repurchase puisse créer une dépendance à un éditeur tiers. Vous étiez indépendant en hébergeant votre legacy. Avec le SaaS, vous dépendez du bon vouloir de l'éditeur quant aux mises à jour, à la stabilité, aux prix futurs. Documentez cette décision et assurez-vous que c'est un arbitrage conscient, pas une naïveté. Troisièmement, coordonnez les repurchase avec les autres migrations en termes de données centralisées. Si vous migrez vers AWS, vous allez probablement centraliser les données dans un data lake ou un warehouse (Redshift, Athena, etc.). Certains SaaS exportent difficilement les données ou refusent les intégrations bidirectionnelles. Assurez-vous dès le départ que le SaaS choisi peut « nourrir » votre architecture data AWS, même minimalement. Quatrièmement, considérez les impacts sur les RTO/RPO (Recovery Time Objective, Recovery Point Objective). Avec un logiciel on-premise, vous contrôlez la sauvegarde. Avec un SaaS, l'éditeur contrôle la disponibilité et la récupération. Acceptez ces SLA ou cherchez un logiciel plus critique via une autre approche (rehost sur AWS ou refactor).