Modernisation de logiciel métier Votre logiciel a vécu. Faisons-le évoluer.
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, puis assurons sa maintenance et ses é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
Ce qui vous empêche d’avancer.
Une correction change un résultat ailleurs
Une modification de remise modifie le montant d’anciennes commandes. Le lien entre les deux calculs n’apparaît pas dans les écrans.
Notre intervention
Repérer les règles partagées et conserver des exemples de résultats attendus avant de toucher au code.
Le logiciel fonctionne grâce à des habitudes non écrites
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 intervention
Reconstituer ces opérations avec elle, puis décider lesquelles documenter, corriger ou intégrer à l’application.
Une évolution attendue reste bloquée
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 intervention
Vé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
Tout ne demande pas le même traitement.
Nous relions chaque difficulté à une option de reprise. Voici des exemples de constats et des vérifications nécessaires avant de décider.
L’option à examiner
Stabiliser la maintenance
- Le constat
- Le logiciel répond au besoin, mais les mises en production sont fragiles.
- Avant de s’engager
- Vérifier les sauvegardes, les accès, les tests et la procédure de déploiement.
L’option à examiner
Reprendre le parcours
- Le constat
- Un écran ralentit les utilisateurs, mais les règles de gestion restent valables.
- Avant de s’engager
- Observer les tâches réelles et vérifier quelles fonctions sont encore utilisées.
L’option à examiner
Remplacer ce module
- Le constat
- Une partie bloque les évolutions de toute l’application.
- Avant de s’engager
- Identifier ses dépendances et organiser la cohabitation avec l’existant.
L’option à examiner
Étudier un remplacement
- Le constat
- Le socle ne permet plus les fonctions nécessaires.
- 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
Que deviennent les dossiers en cours ?
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.
Définir ce qui déménage
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.
Organiser la cohabitation
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.
Prévoir la sortie de l’ancien outil
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
Avancer avec des points de contrôle.
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.
- 01
Un état des lieux vérifiable
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. - 02
Un lot de reprise et ses critères de validation
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. - 03
Des essais sur l’existant et la nouvelle version
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. - 04
Un plan de mise en service
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.
Tierce maintenance applicative (TMA)
Après la reprise, nous assurons la maintenance.
Nous prenons en charge la maintenance de votre application dans la durée, y compris si elle a été développée par un autre prestataire. La prise en charge commence par un état des lieux : accès, sources, sauvegardes et procédure de déploiement.
Corriger les anomalies
Chaque incident est qualifié, corrigé, puis vérifié sur des cas réels avant la mise en production. Les corrections sont tracées.
Faire évoluer les fonctions
Les évolutions demandées par vos équipes sont estimées, priorisées avec vous et livrées par petits lots.
Maintenir le socle technique
Mises à jour de sécurité, dépendances, versions du langage et du serveur : l’application reste compatible avec son environnement.
Ce que nous fixons avec vous avant de démarrer.
Le périmètre couvert, les délais de prise en charge selon la gravité, le mode de facturation, les personnes à prévenir et le suivi des interventions. Ces points sont écrits dans la proposition, pour que chacun sache qui fait quoi.
Une réalisation Aktislab.
Questions fréquentes
Les questions à régler avant de démarrer.
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.
Oui. Nous assurons la maintenance corrective, évolutive et technique de logiciels métier, y compris quand ils ont été développés par un autre prestataire. Nous commençons par un état des lieux des accès, des sources et de la procédure de déploiement, puis nous fixons avec vous le périmètre, les délais de prise en charge et le mode de facturation.
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.
Montrez-nous ce qui bloque dans votre logiciel.
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.