Préparer la transition vers une application métier refondue

Une refonte transforme un outil que vos équipes continuent souvent d’utiliser au quotidien. Sa préparation doit préciser comment les fonctions, les données et les usages passent de l’existant à la nouvelle version.

Selon l’architecture, cette transition peut comprendre une période de coexistence ou nécessiter une mise en service regroupant plusieurs lots. Les décisions concernent aussi les connexions avec les autres logiciels, les accès, la maintenance et les conditions d’arrêt de l’ancien outil.

Comment faire cohabiter l’ancienne et la nouvelle application pendant une refonte ?

Pour organiser cette coexistence, définissez les opérations réalisées dans chaque version, les données qui font référence et les échanges nécessaires entre les deux. Précisez également les responsabilités, les vérifications attendues et les conditions permettant de terminer cette organisation temporaire.

Un découpage du développement en lots ne suffit pas à rendre chaque lot utilisable séparément. La faisabilité dépend des fonctions partagées, des données et des connexions avec les autres outils.

Pour chaque étape, les utilisateurs doivent savoir où créer une information, poursuivre un traitement ou consulter un historique. Par exemple, si les nouveaux dossiers sont ouverts dans la nouvelle application tandis que les dossiers en cours restent dans l’ancienne, il faut définir comment leurs informations seront consultées et leurs traitements terminés.

Lorsque les deux versions utilisent une même donnée, précisez où elle peut être modifiée et comment son actualisation devient accessible à l’autre version. Les mécanismes nécessaires sont à étudier selon l’architecture et les contraintes d’utilisation.

Comment reprendre et vérifier les données lors de la refonte d’une application métier ?

Commencez par définir les données réellement nécessaires dans la nouvelle application : dossiers actifs, historiques, référentiels, pièces jointes ou informations utiles aux traitements. Une refonte ne nécessite pas systématiquement de transférer toute la base existante.

Précisez ensuite les correspondances entre les données actuelles et leur organisation dans la cible : identifiants, formats, statuts, relations entre dossiers et règles de transformation. Les informations incomplètes ou incohérentes doivent être identifiées pour décider de leur traitement.

Les essais de reprise doivent permettre de comparer les résultats obtenus aux résultats attendus.

Un nombre de dossiers identique dans les deux systèmes ne suffit pas à confirmer leur bonne reprise. Les contrôles techniques doivent être complétés par des vérifications métier.

Enfin, prévoyez le traitement des informations créées ou modifiées entre les essais et la bascule, ainsi que les personnes chargées de valider les résultats.

Comment préserver les connexions avec les autres logiciels pendant une refonte ?

Inventoriez les échanges qui permettent à l’application de fonctionner avec votre système d’information : ERP, CRM, outils de reporting, services externes ou transferts de fichiers.

Pour chaque flux, identifiez les informations échangées, leur origine, leur destination, leur fréquence et le responsable de son fonctionnement. Examinez ensuite ce que la refonte modifie : adresse d’un service, format, identifiant, mécanisme d’authentification ou règle de traitement.

Pendant une coexistence, précisez quelle version émet ou reçoit chaque échange. Cette répartition permet de préparer les adaptations et d’éviter qu’un même événement soit traité deux fois.

Les essais doivent couvrir les échanges attendus, mais aussi les erreurs, les données manquantes et l’indisponibilité d’un outil. Les interventions des éditeurs, hébergeurs ou autres prestataires doivent être intégrées au calendrier.

Pour approfondir la préparation des échanges, consultez notre guide pour connecter une application métier aux outils existants.

Que prévoir si la mise en production de l’application refondue doit être annulée ?

Préparez avant la bascule les situations pouvant conduire à reporter la mise en service, à interrompre son déroulement ou à revenir à un fonctionnement antérieur. Définissez les critères de décision, la personne habilitée à arbitrer, les intervenants nécessaires et les vérifications à effectuer.

Le scénario dépend du moment où la difficulté apparaît. Avant l’ouverture aux utilisateurs, il peut encore être possible de reporter le lancement. Après de nouvelles opérations, il faut aussi traiter les données créées ou modifiées et les actions déjà transmises aux autres logiciels.

Une sauvegarde antérieure ne contient pas ces nouvelles informations. Son existence ne suffit donc pas à établir qu’un retour arrière sera possible dans les conditions attendues.

Les essais doivent examiner la restauration, la compatibilité des versions et le délai nécessaire pour reprendre l’activité. Selon la situation, corriger la nouvelle version peut être préférable à un retour sur l’ancienne. Les possibilités et leurs limites doivent être connues avant la mise en production.

Comment revoir les droits d’accès et protéger les données pendant une refonte ?

Repartez des rôles et des responsabilités actuels pour définir les autorisations nécessaires dans la nouvelle application. Les anciens droits peuvent contenir des permissions devenues inutiles ou ne plus correspondre aux usages prévus.

Examinez les comptes des utilisateurs, les accès d’administration et les comptes utilisés par les logiciels pour communiquer entre eux. Précisez qui valide les autorisations et quand les accès temporaires doivent être retirés.

Pendant la transition, ces vérifications concernent les deux versions, les environnements de test, les copies de données et les sauvegardes. Les échanges et les informations stockées doivent bénéficier de protections adaptées à leur sensibilité.

Privilégiez des données fictives ou anonymisées pour les essais. Lorsqu’un besoin justifie l’utilisation de données personnelles hors production, ses conditions et ses protections doivent être examinées avec les responsables concernés.

Les tests doivent vérifier les actions autorisées et les refus attendus, notamment pour consulter, modifier, exporter ou supprimer une information.

Comment maintenir la séparation des données clients lors de la refonte d’une application multi-clients ?

La séparation doit être vérifiée sur l’ensemble des fonctions qui utilisent les données d’un client : consultation, recherche, documents, exports, interfaces et traitements automatiques. L’identification du client concerné et les autorisations doivent rester cohérentes tout au long de ces opérations.

Préparez des essais avec plusieurs clients distincts et plusieurs profils. Vérifiez qu’un utilisateur retrouve les informations auxquelles il a droit et qu’il ne peut pas accéder à celles d’un autre client. Ces contrôles doivent également couvrir les échanges entre l’ancien et le nouveau système pendant leur coexistence.

La reprise doit conserver les bons rattachements : un dossier, une pièce jointe ou une référence ne doit pas être associé au mauvais client.

Dans un projet de refonte présenté sur notre site, la séparation reposait sur un schéma de base de données dédié à chaque client. Ce choix répondait à ce contexte particulier. L’architecture retenue pour un autre projet doit être examinée et ses contrôles d’isolation vérifiés.

Comment organiser la maintenance de l’ancienne application pendant la refonte ?

Définissez le périmètre à maintenir tant que l’ancienne application reste utilisée : corrections, mises à jour nécessaires, assistance et suivi de son fonctionnement. Identifiez les responsables de chaque version et le circuit de traitement des demandes.

Chaque demande doit préciser l’application concernée et être qualifiée : anomalie, difficulté d’utilisation ou évolution. Une correction urgente peut rester nécessaire dans l’ancien outil, tandis qu’une nouvelle fonctionnalité peut être réservée à la cible après arbitrage.

Lorsqu’une correction modifie une règle également présente dans la nouvelle application, examinez ses conséquences sur les deux versions. La solution technique et les vérifications peuvent différer.

Coordonnez les interventions avec les mises en service prévues et les périodes sensibles de l’activité. Le maintien simultané des deux périmètres, ses coûts et ses conditions de fin doivent être précisés dans les accords du projet.

Découvrez les modalités de notre tierce maintenance applicative.

Quand peut-on arrêter l’ancienne application après une refonte ?

L’arrêt peut être envisagé lorsque les usages concernés sont pris en charge par la nouvelle version, que les données nécessaires sont accessibles et que les connexions ne dépendent plus de l’ancien outil. La décision doit s’appuyer sur des vérifications et des validations explicites.

Examinez notamment les opérations courantes, les exceptions importantes, les dossiers encore ouverts, les traitements planifiés et les besoins de consultation des historiques. Les équipes doivent également disposer des accès et des informations nécessaires pour travailler dans la nouvelle application.

L’arrêt de l’utilisation, la fin de maintenance et la suppression des données correspondent à des décisions distinctes. Certaines informations peuvent devoir être conservées avec des conditions d’accès et une durée adaptées à leur finalité ou aux obligations applicables.

Préparez ensuite le retrait des accès, des connexions et des ressources devenues inutiles. Le traitement des archives et des sauvegardes doit suivre les règles définies pour les données concernées.

L’arrêt définitif doit aussi tenir compte de ses conséquences sur les possibilités de retour arrière.

Préparer la transition avec IOcean

Chez IOcean, la préparation part de votre application réelle, de ses usages et de ses contraintes. L’analyse métier et technique aide à déterminer ce qui doit être conservé, adapté ou reconstruit.

Les spécifications, les démonstrations et la recette permettent ensuite de partager les attentes et de vérifier les résultats. Le calendrier de mise en service se prépare avec vos équipes et les intervenants concernés, selon les dépendances techniques et les périodes d’activité.

Les modalités de coexistence, de reprise, de maintenance et de retrait de l’ancien système sont à préciser pour le projet.

Découvrez notre accompagnement pour la refonte d’application métier.