Modernisation de logiciel métier
Chaque modification devient compliquée, l’interface freine les équipes ou le prestataire n’est plus là. Nous examinons votre application, reprenons ce qui peut l’être et préparons les évolutions avec les personnes qui l’utilisent.
Une équipe basée à Lyon. Des échanges directs avec les développeurs, votre référent métier et votre équipe technique.
Reprendre un outil qui compte
Une modification de remise modifie le montant d’anciennes commandes. Le lien entre les deux calculs n’apparaît pas dans les écrans.
Notre interventionRepérer les règles partagées et conserver des exemples de résultats attendus avant de toucher au code.
Une personne sait quels dossiers retraiter, dans quel ordre lancer les exports et quel message d’erreur ignorer. Son départ rend ces tâches incertaines.
Notre interventionReconstituer ces opérations avec elle, puis décider lesquelles documenter, corriger ou intégrer à l’application.
Un portail client doit accéder aux dossiers, mais l’application ne propose pas d’interface adaptée. Une refonte complète est évoquée sans autre option chiffrée.
Notre interventionVérifier si une connexion ou la reprise d’un module suffit, et identifier les dépendances qui imposeraient un chantier plus large.
Les décisions issues de l’audit
Nous relions chaque difficulté à une option de reprise. Voici des exemples de constats et des vérifications nécessaires avant de décider.
Le constat
Le logiciel répond au besoin, mais les mises en production sont fragiles.
L’option à examiner
Avant de s’engager
Vérifier les sauvegardes, les accès, les tests et la procédure de déploiement.
Le constat
Un écran ralentit les utilisateurs, mais les règles de gestion restent valables.
L’option à examiner
Avant de s’engager
Observer les tâches réelles et vérifier quelles fonctions sont encore utilisées.
Le constat
Une partie bloque les évolutions de toute l’application.
L’option à examiner
Avant de s’engager
Identifier ses dépendances et organiser la cohabitation avec l’existant.
Le constat
Le socle ne permet plus les fonctions nécessaires.
L’option à examiner
Avant de s’engager
Comparer les coûts, les risques de migration et les possibilités de récupérer les données.
Le point sensible : la bascule
Remplacer un écran ne transfère pas automatiquement son historique. Une commande déjà commencée, une pièce jointe ou un calcul ancien peuvent dépendre d’informations que la nouvelle version ne connaît pas encore.
Dossiers actifs, historiques consultables, documents et identifiants : le périmètre se décide avant la migration. Certains historiques peuvent rester dans une archive accessible plutôt que d’être reconstruits.
Pour chaque fonction, il faut savoir dans quelle version les utilisateurs travaillent et où les nouvelles données sont enregistrées. Deux logiciels modifiables en parallèle demandent des règles de synchronisation.
Nous fixons les contrôles à passer et les dépendances à retirer avant son arrêt. Tant que les deux versions tournent, elles doivent être hébergées, surveillées et maintenues.
Le retour arrière a des limites. Après de nouvelles saisies dans la version modernisée, restaurer une ancienne sauvegarde peut faire perdre ces opérations. Il faut prévoir leur reprise, ou choisir une autre procédure. Microsoft détaille cette contrainte dans son guide de remplacement progressif.
La reprise, étape par étape
Chaque étape prépare la suivante. Le calendrier dépend de l’état de votre application, des accès disponibles et des validations métier.
Notre façon de travailler →Les sources et accès disponibles, les dépendances identifiées, les parcours examinés et les zones non vérifiées. Les constats distinguent ce qui a été observé de ce qui demande encore une investigation.
La fonction concernée, les comportements à conserver, les corrections attendues et les dépendances à traiter. Les hypothèses qui peuvent modifier le chiffrage sont explicites.
Les mêmes dossiers représentatifs sont utilisés pour comparer calculs, droits, documents produits et échanges externes. Les différences voulues sont validées avec le métier.
Qui arrête les écritures si nécessaire, lance la reprise et vérifie les résultats ? À quel moment peut-on encore revenir en arrière ? La maintenance et la passation sont définies avant la bascule.
Une réalisation Aktislab
Nous sommes intervenus sur la plateforme de formation Tactileo pour améliorer l’accessibilité : navigation, formulaires, contrastes et descriptions des médias. Le travail comprenait aussi l’accompagnement de l’équipe dans ses pratiques de développement. Cette référence porte sur l’amélioration de l’application existante, notamment son accessibilité.
Découvrir notre intervention →Oui, après vérification des droits, des sources et des accès disponibles. Un dépôt de code ne suffit pas toujours : il faut aussi les dépendances, la configuration et les éléments nécessaires pour reconstruire et déployer l’application. Les manques sont recensés avant de s’engager sur les évolutions.
Pas systématiquement. Un problème d’usage peut se résoudre dans les écrans ; une difficulté de maintenance peut venir du déploiement ou des tests. Le changement de technologie se discute lorsque le support, les dépendances ou les besoins à venir le justifient. Il ne remplace pas l’analyse des règles métier.
Nous pouvons croiser le code, la structure des données et les explications des utilisateurs pour reconstituer les comportements. Certaines règles demandent des exemples historiques pour être comprises. L’audit précise ce qui a pu être confirmé et ce qui reste incertain.
Le nombre de lignes transférées est un premier contrôle, pas une preuve suffisante. Il faut aussi vérifier les liens entre dossiers, les pièces jointes, les statuts et les résultats de calcul sur des cas convenus. Vos équipes valident les écarts et les données qui doivent rester consultables dans l’ancien outil.
Il peut inclure la reconstitution des règles, les tests, le nettoyage et la migration des données, ainsi que l’exploitation temporaire de deux versions. La durée de cette cohabitation et les conditions d’arrêt de l’ancien outil doivent être prévues pour éviter de financer durablement les deux.
Un incident qui revient, une évolution reportée ou un écran que l’équipe évite : c’est un point de départ concret pour examiner la reprise.