Refonte logiciel : décider ce qui mérite d’être reconstruit
Une refonte application peut concerner les écrans, les règles métier ou l’organisation des données. Ces chantiers ne sont pas interchangeables. Une base SQL Server encore adaptée peut rester en place pendant que l’interface change. Inversement, reproduire les écrans à l’identique ne règle pas les règles contradictoires ni les doublons de données.
L’inventaire de l’existant permet de préciser ce qui fonctionne et ce qui bloque. Croisez-le avec les risques de dette technique et les usages attendus. Le périmètre doit nommer ce qui est conservé, remplacé et abandonné. Faites arbitrer les fonctions rarement utilisées avant de les supprimer.
- Écrans : saisie, recherche et validation.
- Règles : calculs, statuts et exceptions.
- Données : référentiels, historique et correspondances.
- Échanges : comptabilité, fichiers, courriels et outils voisins.
Comparer les trajectoires avant le devis
| Trajectoire | Intérêt à examiner | Point à résoudre |
|---|---|---|
| Correction ciblée | Préserver un outil qui couvre encore les besoins | Capacité réelle à maintenir les composants. |
| Nouvelle interface sur base conservée | Revoir les accès et les usages sans déplacer toutes les données | Règles existantes et contrats d’échange. |
| Remplacement par fonctions | Valider des périmètres successifs | Coexistence, référence des données et dépendances. |
| Remplacement global | Traiter un périmètre dont le découpage n’est pas pertinent | Reprise complète, recette et bascule répétée. |
Microsoft décrit dans le pattern Strangler Fig une modernisation par fonctions. Cette approche suppose notamment que l’on puisse intégrer ou intercepter les échanges de l’ancien système. Elle ne convient donc pas automatiquement à toute base Access ou application fermée.
Écrire les règles à conserver avant de réécrire
Recueillez les parcours des personnes qui utilisent l’application, y compris les traitements périodiques. Faites décrire les corrections manuelles après export : elles signalent parfois une règle absente du logiciel. Reliez ces décisions aux spécifications fonctionnelles et aux résultats attendus en recette.
- Documenter un dossier de bout en bout avec ses exceptions.
- Lister les interfaces et les personnes qui en dépendent.
- Définir les règles et données de référence du nouveau périmètre.
- Faire approuver les critères de réception avant réalisation.
La reprise des données est un chantier distinct. Prévoyez les correspondances d’identifiants et le traitement des archives dans le plan de reprise de la base. Une décision de réécriture ne fixe pas à elle seule l’historique à reprendre.
Préparer la continuité et le retour arrière
Déterminez qui peut saisir dans chaque système durant la transition. La coexistence devient risquée si les mêmes dossiers sont modifiés de part et d’autre sans règle de rapprochement. Définissez le système de référence pour chaque fonction et les conditions de passage au nouveau périmètre. Le plan de migration applicative formalise les contrôles et les décisions de bascule.
Comparer des propositions sur les mêmes livrables
Demandez des lots explicitant les fonctions reprises, les interfaces, les essais et la documentation livrée. Séparez la construction initiale de l’hébergement et de la maintenance. Vérifiez aussi l’accès au dépôt et la possibilité de faire reprendre le logiciel. La comparaison porte sur les exclusions autant que sur les fonctions annoncées.
- Liste des fonctions et règles validées.
- Rapport de reprise et résultats de recette.
- Procédure de publication et de restauration.
- Documentation et conditions de maintenance.
Questions pratiques
Une refonte oblige-t-elle à changer de base de données ?
Non. Faites examiner la base et les besoins de l’interface séparément. Le choix dépend des contraintes techniques relevées et des usages visés, puis des tests sur le périmètre retenu.
Comment vérifier que la refonte répond au besoin ?
Associez les utilisateurs à la recette et conservez les cas testés, les résultats et les anomalies. Microsoft présente ce rôle des utilisateurs métier dans sa documentation sur les tests d’acceptation : organiser une recette utilisateur.
Sources officielles
Références vérifiées le 20 octobre 2026. Les grilles proposées servent à préparer le projet avec vos responsables métier et techniques.