Migrer une application Windows vers le Web : les cas à éviter — tableau de décision et la solution réaliste du « fractionnement »

« Nous aimerions bientôt migrer vers le Web l’application Windows que nous utilisons en interne » — ce type de demande revient de plus en plus souvent. La motivation est fréquemment légitime, mais en creusant, on découvre régulièrement des équipes sur le point de migrer intégralement vers le Web une application qui, de ce fait, deviendrait plus difficile à utiliser et plus coûteuse.

Précisons d’emblée : cet article ne dit pas qu’il « ne faut jamais migrer vers le Web ». Il existe de nombreuses situations — usage depuis plusieurs sites, réduction de la gestion des postes — où la migration Web est clairement la bonne réponse. Le problème est de traiter en bloc, sous l’étiquette « modernisation = migration Web », des applications dont la nature ne s’y prête pas. Cet article présente la méthode que nous utilisons concrètement, dans notre pratique du développement Windows sur mesure, pour repérer les cas où il vaut mieux ne pas migrer vers le Web, et propose le fractionnement comme solution réaliste, plutôt que le choix binaire entre « tout Web » et « tout Windows ».

1. La conclusion d’abord (tableau de décision)

L’essentiel est de raisonner non pas sur l’application dans son ensemble, mais fonction par fonction, selon la nature de chacune.

Voici d’abord la conclusion.

• Les demandes de « passage au Web » mélangent généralement trois problèmes distincts : la contrainte de distribution, les restrictions de lieu d’utilisation, et l’obsolescence technologique. Chacun appelle une solution différente, et la migration Web n’est la seule réponse que pour une partie d’entre eux (chapitre 2).
• Les applications avec intégration d’appareils, traitement de fichiers locaux ou fonctionnement hors ligne sont plus sûres si l’on n’en migre pas cette partie vers le Web. Les navigateurs restreignent délibérément l’accès aux ressources locales pour des raisons de sécurité — ce n’est pas un défaut du Web, mais un choix de conception¹. Des contournements existent, mais ils introduisent d’autres coûts : navigateurs compatibles limités, exploitation plus complexe (chapitres 3 à 5).
• La migration Web est une refonte, pas un portage. Les écrans existants ne peuvent pas être repris tels quels, et une fois le projet terminé, un nouveau coût continu apparaît : l’exploitation du serveur. Si le devis ne part pas de ce postulat, le plan s’effondrera en cours de route (chapitre 7).
• La solution réaliste est le fractionnement. Porter la consultation, l’agrégation et les rapports sur le Web, conserver l’intégration d’appareils et la saisie terrain en Windows, et relier le tout par une API et une base de données communes. On peut ainsi démarrer plus petit qu’une migration complète et avancer par ordre d’impact (chapitre 8).

2. Décomposer ce que recouvre « nous voulons passer au Web »

Lorsqu’on nous sollicite pour une migration Web, la première étape consiste à décomposer la demande. Derrière l’expression « nous voulons passer au Web » se cache généralement l’un des trois éléments suivants (ou plusieurs à la fois).

(1) Éliminer la contrainte de distribution et de mise à jour. La plainte ressemble à : « à chaque nouvelle version, nous devons faire le tour de tous les postes pour l’installer ». La migration Web résout effectivement ce problème, mais on peut le résoudre sans migrer vers le Web. En passant à un mode de distribution doté d’une mise à jour automatique, comme ClickOnce ou MSIX, on peut ramener le travail de distribution à quasiment zéro tout en conservant une application Windows. Nous détaillons ce point dans « Comment choisir la méthode de distribution d’une application Windows ». Si la contrainte de distribution est la seule motivation, la migration Web est un investissement disproportionné.

(2) Pouvoir l’utiliser depuis n’importe où et n’importe quel poste. Usage depuis plusieurs sites, accès depuis un client ou son domicile, consultation sur tablette — c’est là que la migration Web excelle vraiment. Mais même ici, il faut distinguer « vouloir utiliser toutes les fonctions depuis n’importe où » de « vouloir simplement consulter les données depuis n’importe où ». En pratique, c’est souvent le second cas, pour lequel une architecture fractionnée (chapitre 8) portant sur le Web uniquement la consultation et l’agrégation suffit.

(3) S’éloigner d’une technologie ancienne. La motivation ressemble à : « la personne qui l’a développée a quitté l’entreprise » ou « nous sommes inquiets de rester sur .NET Framework ». C’est une préoccupation légitime, mais la solution n’est pas forcément la migration Web. Si l’on doit de toute façon reconstruire, et que la nature du travail se prête à un usage bureautique, il existe l’option de reconstruire l’application Windows avec un .NET récent (« Tableau de décision pour choisir entre WinForms, WPF et WinUI »). Il faut aussi garder à l’esprit que passer au Web ne met pas à l’abri de l’obsolescence. Le cas bien connu d’un système Web interne conçu uniquement pour IE, resté sans issue après l’arrêt d’IE, en est une illustration frappante (« Prolonger la vie d’un système Web interne dépendant du mode IE, et sa stratégie de sortie »). Les applications Web nécessitent elles aussi une maintenance pour suivre les évolutions des frameworks et des navigateurs : « passer au Web » ne signifie pas « être libéré de la maintenance ».

Cette décomposition permet de distinguer ce que seule la migration Web résout, ce que d’autres approches résolvent aussi, et ce que la migration Web ne résout pas du tout. Il faut ensuite vérifier si l’application comporte des fonctions correspondant aux cas « à éviter pour la migration Web » décrits ci-dessous.

3. Cas 1 : connexion directe à des appareils ou périphériques

Communication avec des machines de production, récupération de données depuis des instruments de mesure ou de contrôle, balances ou lecteurs de codes-barres connectés en série (RS-232C), pilotage fin d’imprimantes spécialisées — les applications dotées de fonctions dialoguant directement avec le matériel se prêtent structurellement mal à une migration Web de cette partie.

La raison est simple : le code exécuté dans un navigateur tourne dans un environnement isolé appelé bac à sable (sandbox). Il serait problématique qu’une simple ouverture de page Web permette de manipuler librement les fichiers ou appareils de la machine ; les navigateurs bloquent donc délibérément l’accès aux ressources locales. Ce n’est pas un défaut du Web, mais la conception sécuritaire elle-même. Ainsi, même avec Blazor WebAssembly, qui permet d’écrire un client Web en C#, le code s’exécute dans le bac à sable de sécurité du navigateur, et l’accès au système de fichiers ou l’ouverture d’une connexion réseau arbitraire déclenche une PlatformNotSupportedException¹. Ce qui est possible se limite au périmètre des capacités du navigateur².

On pourrait objecter que « la Web Serial API ou WebUSB permettent la communication série depuis un navigateur ». C’est vrai, mais la compatibilité des navigateurs reste limitée. La Web Serial API est prise en charge par les navigateurs de la famille Chromium (Chrome, Edge, etc.), et depuis Firefox 151, sorti en mai 2026, également par Firefox de bureau — mais Safari reste non compatible (et côté mobile, Chrome pour Android n’offre qu’une prise en charge partielle, via Bluetooth), tandis que WebUSB demeure exclusif à Chromium³. En plus de restreindre le principal avantage de la migration Web — « utilisable depuis n’importe quel navigateur » —, l’utilisateur doit sélectionner et autoriser l’appareil via une boîte de dialogue du navigateur (au moins la première fois, ou à chaque ajout d’appareil), ce qui rend souvent ce choix peu rentable comme mécanisme d’intégration d’appareils pour une application métier.

Il existe aussi une solution de contournement consistant en une « application Web accompagnée d’un agent d’intégration résident sur chaque poste », mais il s’agit d’une architecture où un programme Windows nécessitant distribution et mises à jour subsiste malgré tout. Ce n’est pas mauvais en soi — c’est même une forme du fractionnement décrit au chapitre 8 —, mais il faut absolument le signaler dès la phase de cadrage : ce n’est pas la même chose que l’attente initiale selon laquelle « migrer vers le Web dispenserait d’installer quoi que ce soit sur les postes ».

Pour la conception de la partie intégration d’appareils, voir aussi « Bonnes pratiques pour la vérification et l’affichage de l’état des appareils externes ».

4. Cas 2 : intégration profonde avec des fichiers locaux ou d’autres applications

Le deuxième cas fréquent est celui où le travail avec des fichiers présents sur le poste, ou avec d’autres applications, constitue le cœur du processus métier.

• Surveiller un dossier partagé ou local et traiter automatiquement les fichiers qui y sont déposés
• Convertir, renommer ou trier en masse des centaines, voire des milliers de fichiers
• Lancer Excel et assembler des rapports via COM, ou s’interfacer avec des macros Excel existantes
• Échanger des données avec d’autres applications métier via des fichiers ou une communication inter-processus

La règle générale de l’accès aux fichiers depuis un navigateur limite celui-ci « aux fichiers que l’utilisateur a lui-même sélectionnés via une boîte de dialogue, à cette occasion ». Il n’existe aucun moyen d’accès en masse sans intervention de l’utilisateur, ni de surveillance résidente continuant de fonctionner navigateur fermé. Les ajouts récents comme la File System Access API permettent un accès limité à un dossier choisi par l’utilisateur, et une API expérimentale (FileSystemObserver) permet même de surveiller les modifications d’un dossier sélectionné tant que la page reste ouverte — mais ces fonctionnalités restent réservées à Chromium⁴, avec le même problème de « verrouillage sur des navigateurs compatibles » que pour l’intégration d’appareils. Quant à lancer et piloter depuis le navigateur un autre processus local, comme Excel, il n’existe tout simplement aucun moyen d’y parvenir.

Migrer ce type de fonction vers le Web impose de faire évoluer le processus métier vers un modèle où l’utilisateur téléverse les fichiers vers le serveur, qui les traite ensuite. Si le métier peut fonctionner ainsi, c’est une option envisageable ; mais si l’on doit traiter au quotidien des fichiers de plusieurs gigaoctets, traiter localement des données qui ne peuvent pas sortir de l’entreprise, ou dépendre étroitement d’existants Excel, il est plus raisonnable — tant pour le développeur que pour l’utilisateur — de conserver cette partie en application Windows (ou en service Windows, pour les traitements sans surveillance humaine comme la surveillance de dossiers ou le traitement en masse). Un point spécifique mérite attention : l’intégration COM avec Excel. Microsoft déconseille et ne prend pas en charge l’automatisation d’Office depuis des environnements non interactifs et sans surveillance⁵ ; le code pilotant Excel automatiquement doit donc se trouver côté application de bureau, exécutée par un utilisateur connecté, ou être remplacé par la lecture/écriture via une bibliothèque basée sur Open XML qui ne lance pas Office. La construction de l’intégration Excel est traitée dans « Comment construire une sortie de rapports Excel », et la surveillance de dossiers dans « Les bases sûres de FileSystemWatcher ».

5. Cas 3 : utilisation sur des sites au réseau instable, pour des tâches qui ne peuvent pas s’interrompre

Par nature, une application Web suppose que la connexion réseau est active. C’est vrai des applications Web à rendu côté serveur, mais aussi de Blazor Server, populaire dans l’écosystème C#, où chaque interaction de l’interface est traitée via une connexion permanente au serveur : dès que la connexion tombe, l’application cesse de fonctionner. La documentation officielle précise noir sur blanc qu’il n’existe aucune prise en charge du hors ligne².

Cela pose problème dans des environnements tels que :

• Usines, entrepôts, sites extérieurs : le signal Wi-Fi bloqué par des étagères métalliques ou des machines, avec des micro-coupures quotidiennes
• Lignes qui ne peuvent pas s’arrêter : un écran d’enregistrement ou d’instructions figé quelques minutes seulement affecte la production ou les expéditions
• Sites à la connexion faible ou instable : bureaux temporaires dépendant du réseau mobile, navires, zones montagneuses, etc.

Une application Windows native peut naturellement être conçue pour conserver les données localement, continuer à fonctionner hors ligne, et se synchroniser une fois la connexion rétablie. Le fonctionnement hors ligne est d’ailleurs cité par Microsoft lui-même comme une raison de choisir une application native⁶. Il est techniquement possible de rendre une application Web compatible hors ligne, via une PWA (service worker) ou une conception conservant les données côté client, mais construire cela — synchronisation et résolution des conflits comprises — représente un investissement supplémentaire conséquent, allant à l’encontre de l’attente initiale selon laquelle « migrer vers le Web réduirait les coûts ».

Le critère décisif est le suivant : « si le réseau tombe pendant 30 minutes, ce processus métier peut-il attendre ? ». Si la réponse est non, l’écran gérant ce processus doit au moins fonctionner localement.

6. Cas 4 : la saisie rapide et massive au clavier est au cœur du métier

Saisie de bons, contrôle et enregistrement des expéditions, écrans de réponse en centre d’appels — des métiers où l’on passe sa journée devant cet écran, à saisir de grands volumes de données, principalement au clavier. C’est un domaine où l’interface de bureau a atteint un haut niveau d’aboutissement, et où la migration Web tend à dégrader sensiblement la qualité perçue.

• Latence de réponse : avec des modèles connectés au serveur comme Blazor Server, chaque action de l’utilisateur implique un aller-retour réseau, augmentant la latence de l’interface². Même quelques dizaines de millisecondes par action se ressentent nettement, sur des milliers d’opérations quotidiennes, comme une sensation de « lenteur ».
• Reproduction des comportements clavier : des évidences du métier de saisie — passage au champ suivant avec Entrée, affectation des touches de fonction, validation instantanée pendant la frappe — se heurtent au comportement par défaut du navigateur (Entrée qui soumet un formulaire, F1 qui ouvre l’aide, etc.) et doivent être reconstruites en composant avec ces conflits. Ce n’est pas impossible, mais cela revient à payer un coût supplémentaire pour rattraper une qualité que les frameworks et composants de grille du bureau offrent d’emblée.
• Grilles de données volumineuses : réaliser sur le Web une grille de niveau bureautique, affichant fluidement des dizaines de milliers de lignes en défilement virtuel, avec édition de cellules, colonnes figées et copier-coller, nécessite l’adoption d’un composant commercial très complet et un travail de réglage conséquent.

Pour de la consultation, des validations ou des saisies occasionnelles, un formulaire Web suffit largement. Mais pour un écran où la vitesse de saisie conditionne directement la productivité du métier, il faut vérifier calmement si l’on bénéficiera réellement de l’avantage de la migration Web (utilisable depuis n’importe où) — ou si cet écran ne sera, en définitive, utilisé que depuis un poste fixe au bureau. Si le lieu d’utilisation est fixe, la migration Web n’apporte rien et ne fait que retirer.

7. Cas 5 : entamer une « refonte » en la budgétant comme un « portage »

Jusqu’ici, il s’agissait de fonctions et de modes d’usage ; le dernier point concerne la structure de coûts. Le schéma classique par lequel un projet de migration Web s’effondre en cours de route est de le budgéter comme un portage — « transposer l’existant vers le Web » — pour découvrir plus tard qu’il s’agissait en réalité d’une refonte.

• Les écrans existants ne se transposent pas. Il n’existe pas de moyen réaliste de convertir automatiquement vers le Web les définitions d’écrans et la logique de WinForms ou WPF ; l’interface doit être repensée et reconstruite écran par écran. Le nombre d’écrans multiplié par leur complexité constitue directement la charge de travail.
• Un inventaire de la logique métier est un préalable. Il n’est pas rare qu’une application exploitée depuis longtemps contienne des règles métier absentes de toute spécification et présentes uniquement dans le code. La migration Web implique de tout exhumer et de tout réimplémenter. Ce point rejoint exactement le principe « ne pas se lancer directement dans une réécriture complète » développé dans « Prolonger la vie et migrer les applications métier VB6 / Access ».
• Le coût d’exploitation après livraison augmente structurellement. L’exploitation d’une application de bureau consistait à s’occuper des postes ; avec une application Web apparaissent des tâches continues : construction, supervision, sauvegardes, certificats et mises à jour de sécurité d’un serveur (ou d’un environnement cloud). Sans cette capacité en interne, une prestation externe sera facturée chaque mois. La comparaison des coûts de la migration Web doit intégrer ce coût récurrent, et pas seulement le coût de développement initial.
• Les hypothèses de sécurité changent. Dès qu’une application qui ne fonctionnait qu’au sein du réseau local de l’entreprise passe au Web et autorise un accès externe, les exigences en matière d’authentification, d’autorisation, de chiffrement des communications et de protection contre les attaques montent d’un cran. Cela aussi fait partie du « coût de la migration Web ».

Répétons-le : rien de tout cela ne plaide contre la migration Web — ce sont des éléments pour établir un devis sur des bases correctes. Si, une fois la refonte et les coûts d’exploitation intégrés, les bénéfices de la migration Web l’emportent encore, il faut avancer. Sinon, il convient d’abord d’examiner si moderniser l’application tout en la conservant sous Windows (migration vers le .NET le plus récent, amélioration du mode de distribution, refonte de l’interface) — un investissement bien moindre — peut satisfaire l’essentiel de la motivation.

8. La solution réaliste : ne pas forcer un choix entre tout Web ou tout Windows

En ramenant tout ce qui précède à la pratique, la réponse, dans la plupart des cas, n’est ni « migration Web complète » ni « statu quo », mais le fractionnement.

Le principe est simple : appliquer le tableau de décision du chapitre 1 non pas à l’application entière, mais fonction par fonction.

• À porter sur le Web : consultation, recherche et agrégation des données que plusieurs sites ou personnes doivent voir, téléchargement de rapports, opérations légères comme les validations. La maintenance des données de référence s’y intègre généralement aussi.
• À conserver sous Windows : intégration avec les appareils et périphériques, surveillance et traitement en masse de fichiers locaux, travail de terrain qui ne peut pas s’arrêter même hors ligne, écrans de saisie rapide.
• À mutualiser : la base de données et la logique métier. En centralisant les données, l’application Web et l’application Windows référencent la même API (ou la même base de données). Cette mutualisation permet une architecture qui satisfait l’essentiel de la motivation de la migration Web : « le terrain saisit via l’application Windows, tandis que le siège vérifie instantanément depuis un navigateur ».

Cette architecture présente des avantages pratiques qu’une migration Web complète n’offre pas : un périmètre à reconstruire d’un coup plus réduit, la possibilité d’avancer par étapes en commençant par les parties à fort impact (la consultation), et le maintien du confort d’utilisation sur le terrain. En contrepartie, il faut disposer d’une organisation capable de maintenir deux systèmes — une application Windows et une application Web — donc si l’application visée est petite et principalement centrée sur la consultation, une migration Web complète peut très bien s’avérer le meilleur choix. Là encore, il s’agit d’une question de degré plutôt que d’un choix binaire.

Notons enfin que pour un besoin du type « nous voulons des écrans construits avec des technologies Web, mais devons aussi toucher aux ressources locales », des options hybrides comme Electron ou Blazor Hybrid (WebView2) existent. Elles permettent d’utiliser une interface en technologies Web sans subir les restrictions du bac à sable du navigateur, mais il faut garder à l’esprit qu’il s’agit toujours d’une application de bureau nécessitant une distribution, ce qui ne répond pas à un besoin de « pouvoir l’utiliser uniquement depuis un navigateur ».

9. Liste de vérification avant de décider d’une migration Web

Vérifier les points suivants avant de demander un devis ou de solliciter une validation interne réduit le risque de reprise du travail :

1. Décomposer la motivation : contrainte de distribution, lieu d’utilisation ou obsolescence technologique — lequel est le véritable problème ? Si c’est uniquement la distribution, changer le mode de distribution ne suffirait-il pas ?
2. Présence d’intégration matérielle : existe-t-il des fonctions communiquant directement avec des appareils série/USB, instruments de mesure ou imprimantes spécialisées ? Si oui, déterminer d’abord comment traiter cette partie (conserver sous Windows / architecture avec agent).
3. Dépendance aux ressources locales : y a-t-il surveillance de dossiers, traitement en masse de fichiers, intégration de processus avec Excel ou équivalent ? Le processus métier peut-il évoluer vers un traitement côté serveur ?
4. Exigences hors ligne : si le réseau tombe pendant 30 minutes, ce processus métier peut-il attendre ?
5. Poids du travail de saisie : existe-t-il des écrans où l’on saisit au clavier toute la journée ? Cet écran sera-t-il vraiment utilisé « depuis n’importe où » ?
6. Réalité des utilisateurs et des lieux : qui veut voir ou saisir quoi, et depuis où ? S’agit-il de « tout le monde, toutes les fonctions, depuis l’extérieur » ou simplement « le siège veut consulter les données » ?
7. Organisation d’exploitation : qui assurera la construction, la supervision et les mises à jour de sécurité du serveur ? Quel en sera le coût mensuel ?
8. Localisation de la logique métier : la spécification correspond-elle au code ? Le temps nécessaire à l’inventaire a-t-il été inclus dans le devis ?

Si l’un des points 2 à 5 s’applique, nous recommandons d’envisager en priorité une architecture fractionnée plutôt qu’une migration Web complète. Pour la préparation générale avant de confier un projet, voir aussi « Ce qu’il faut clarifier avant de confier un développement Windows en sous-traitance ».

Résumé

La migration Web est un outil, pas une fin en soi. Elle est clairement efficace pour l’usage depuis plusieurs sites et la réduction de la gestion des postes, mais l’intégration d’appareils et le traitement de fichiers locaux se heurtent à des contraintes issues de la conception sécuritaire du navigateur, difficiles à contourner par le choix d’un framework ou par le travail d’ingénierie ; quant au fonctionnement hors ligne et à la saisie rapide, ils peuvent être pris en charge techniquement, mais le coût de leur construction et de leur exploitation tend à jouer contre l’objectif initial de « simplifier les choses en passant au Web ». Enfin, la migration Web est une refonte et non un portage : une fois terminée, elle ajoute un nouveau coût continu, l’exploitation du serveur.

C’est précisément pour cela que la décision pratique n’est pas « migrer vers le Web ou non », mais une question de conception : « quelles fonctions porter sur le Web, lesquelles conserver sous Windows, et que mutualiser ? ». Passer de l’inventaire de l’application existante à la décision de migration Web puis à la conception d’une architecture fractionnée exige généralement un jugement fondé sur le code et l’exploitation réels ; en cas de doute, n’hésitez pas à nous consulter.

Articles connexes

• Ce qu’il faut clarifier avant de confier un développement Windows en sous-traitance
• Prolonger la vie et migrer les applications métier VB6 / Access — tableau de décision entre conserver, encapsuler et remplacer
• Tableau de décision pour choisir entre WinForms, WPF et WinUI
• Comment choisir la méthode de distribution d’une application Windows (MSI / MSIX / ClickOnce / xcopy / mise à jour maison)
• Prolonger la vie d’un système Web interne dépendant du mode IE, et sa stratégie de sortie
• Bonnes pratiques pour la vérification et l’affichage de l’état des appareils externes
• Les bases sûres de FileSystemWatcher
• Comment construire une sortie de rapports Excel

Domaines de conseil associés

Le cabinet KomuraSoft LLC (合同会社小村ソフト) traite les questions de conseil technique portant sur la pertinence de migrer une application Windows existante vers le Web, la conception d’une architecture fractionnée Web + Windows, ainsi que le développement et la refonte d’applications métier impliquant intégration d’appareils et traitement local.

• Développement d’applications Windows
• Maintenance et refonte de logiciels Windows existants
• Conseil technique / revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Si l'on met à jour une ancienne application Windows, vaut-il mieux la migrer vers le Web au passage ?

Nous déconseillons de migrer vers le Web pour la seule raison que l'application est « ancienne ». La migration Web demande un effort proche d'une refonte complète plutôt que d'un simple portage, et les applications Web connaissent elles aussi l'obsolescence technologique (un système Web interne resté figé sur IE en est un exemple typique). Le critère de décision ne doit pas être l'ancienneté de la technologie, mais l'usage réel de l'application. Si elle est utilisée depuis plusieurs sites et que l'on souhaite réduire la gestion des postes, la migration Web est avantageuse. Mais si l'application repose surtout sur l'intégration d'appareils ou le traitement de fichiers locaux, moderniser l'application Windows telle quelle — migration vers une version récente de .NET, refonte de l'interface — est souvent plus rentable.

La migration vers le Web ne supprime-t-elle pas au moins la contrainte de distribution et d'installation ?

Elle supprime le travail de distribution côté client, mais si c'est votre seule motivation, il existe des solutions plus légères que la migration Web. Passer à un mode de distribution avec mise à jour automatique intégrée, comme ClickOnce ou MSIX, permet de rendre les visites d'installation sur chaque poste quasiment inutiles, tout en conservant une application Windows. Et si vous migrez malgré tout vers le Web, vous prenez en charge un nouveau coût d'exploitation continu : construction, supervision et mises à jour de sécurité d'un serveur (ou d'un environnement cloud). Il faut peser à la fois les coûts qui disparaissent et ceux qui apparaissent avant de trancher.

Peut-on migrer seulement une partie de l'application vers le Web ?

Oui, et en pratique c'est même souvent la solution réaliste. Le schéma typique consiste à porter sur le Web la consultation des données, les agrégations, les rapports et l'accès depuis plusieurs sites, tout en conservant en application Windows l'intégration des appareils, la saisie rapide sur le terrain et le traitement de fichiers locaux — les deux étant reliés par une API et une base de données communes. Comparé à une migration complète, le périmètre à reconstruire d'un coup est plus réduit, et l'on peut avancer progressivement en commençant par les parties où la migration Web apporte le plus de valeur.

Qu'en est-il d'options intermédiaires comme Electron, les PWA ou Blazor Hybrid ?

Ce sont des solutions de nature différente qu'il faut distinguer. Electron et Blazor Hybrid (WebView2) s'exécutent comme des applications de bureau : ils peuvent donc accéder aux fichiers et aux appareils sans subir les restrictions du bac à sable du navigateur, tout en permettant d'écrire l'interface avec des technologies Web. Cela reste toutefois des applications de bureau nécessitant distribution et mises à jour, ce qui ne répond pas à un besoin de « pouvoir l'utiliser uniquement depuis un navigateur ». À l'inverse, une PWA peut donner une impression d'application installée (épinglage à la barre des tâches, par exemple), mais reste en réalité une application Web s'exécutant dans le navigateur, avec les mêmes restrictions d'accès aux ressources locales qu'une application Web classique. Il est essentiel de commencer par décomposer précisément le problème que l'on cherche à résoudre en envisageant une migration Web.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.