Je reviens à la même question depuis quelques jours : pour une nouvelle application, est-ce que je partirais en WinForms ou en ASP.NET? Les deux utilisent .NET et peuvent appeler les mêmes bibliothèques métier, mais leur boucle d’exécution n’habite pas au même endroit.

Une application WinForms est un processus installé sur le poste. Windows lui remet les messages de souris, clavier et peinture; les contrôles gardent leur état en mémoire jusqu’à la fermeture. Le code peut lire un port série, ouvrir un fichier local ou dessiner une grille dense sans aller au serveur pour chaque interaction. Si le réseau tombe, l’interface continue et peut même travailler avec une copie locale, à condition d’avoir conçu la synchronisation.

poste Windows
messages → contrôles WinForms → logique .NET → réseau → serveur/SQL
             ↳ état en mémoire, fichiers et périphériques locaux

Le prix arrive au déploiement. Il faut la bonne version du .NET Framework, les assemblies, la configuration et peut-être des composantes COM sur chaque poste. Un MSI peut installer tout ça, mais une mise à jour interrompue peut laisser deux versions en circulation. Si le client et le serveur changent leur contrat en même temps, l’ancienne application doit recevoir un message compatible au lieu de planter. Je prévoirais un numéro de version dans l’échange et un mécanisme de retour à la version précédente.

ASP.NET déplace l’exécution principale sur IIS. Le navigateur envoie une requête HTTP; le serveur crée ou recharge une page, exécute les événements, produit du HTML, puis oublie normalement l’objet page. Le navigateur affiche le résultat. Comme HTTP est sans état, ASP.NET utilise des champs comme __VIEWSTATE, des cookies et parfois une session serveur pour donner l’impression qu’un contrôle survit entre deux requêtes.

navigateur → HTTP POST → IIS/ASP.NET → logique .NET → SQL Server
           ← HTML + ViewState ← rendu de la page ← résultat

Le ViewState peut devenir lourd si une grosse grille sérialise son état dans chaque réponse. La session stockée en mémoire sur un serveur complique l’ajout d’un deuxième serveur : la prochaine requête doit retourner au même nœud ou la session doit vivre dans un stockage partagé. Une page ouverte depuis longtemps peut aussi envoyer un état périmé et écraser une modification récente; le serveur doit vérifier la concurrence comme pour un client Windows.

Le Web simplifie la distribution : installer une nouvelle version sur le serveur suffit pour le prochain chargement. Il impose toutefois le rythme requête/réponse, les limites du navigateur de 2004 et une frontière de sécurité exposée. Toute validation JavaScript doit être répétée côté serveur. Un identifiant de client dans un champ caché n’autorise pas la personne à lire ce client; chaque requête doit vérifier l’accès.

Mon exemple de décision serait un outil d’inventaire avec lecteur de code-barres :

Besoin	WinForms	ASP.NET
lire un port série local	direct, bien supporté	dépend d’ActiveX ou d’un helper local
continuer dans l’entrepôt sans réseau	cache et file locale possibles	page inutilisable sans serveur
déployer une correction à 80 postes	package et suivi de versions	une publication sur IIS
accéder depuis plusieurs types de postes	client Windows requis	HTML plus accessible

Je pourrais aussi partager la logique métier dans une bibliothèque .NET et donner deux façades différentes aux quelques opérations qui le justifient. Ce n’est pas gratuit : deux interfaces signifient deux tests et deux cycles d’erreur. Mais ça évite de placer les règles de stock seulement dans les boutons WinForms ou les événements ASP.NET.

Avant de choisir, je testerais la panne dominante. Pour WinForms : couper le réseau pendant une synchronisation, redémarrer et vérifier la file sans doublons. Pour ASP.NET : expirer la session, soumettre deux fois le formulaire et déployer pendant une requête. J’estimerais aussi le poids réel du ViewState et le nombre de postes à maintenir.

Il n’y a pas une technologie gagnante. WinForms paie l’installation et la diversité des clients pour gagner une boucle locale riche. ASP.NET paie les allers-retours et la gestion d’état pour gagner un déploiement central. Je veux choisir la panne que l’équipe sait diagnostiquer et la contrainte que le produit peut accepter, pas l’écran qui impressionne le plus dans Visual Studio.