Externalisation et développement sur mesure d'une application Windows : ce qu'il faut clarifier avant de se lancer

Lorsque vous envisagez d’externaliser ou de confier en sous-traitance le développement d’une application Windows, la première décision ne se limite pas à « avec quelle technologie la construire ».

Sur le terrain, nous recevons fréquemment des demandes comme celles-ci :

• Nous voulons faire évoluer un vieux logiciel Windows
• Nous ne parvenons pas à reprendre une application interne créée par un prédécesseur
• La communication avec un équipement ou un instrument de mesure s’interrompt de temps en temps
• Le 32 bits / 64 bits, COM / ActiveX et l’intégration VBA sont tous impliqués
• L’application ne fonctionne plus après un passage à Windows 11 ou un nouveau PC
• Nous voulons tout clarifier, y compris le déploiement, la signature de code, les mises à jour automatiques et les avertissements SmartScreen
• Nous voulons faire investiguer des plantages ou une croissance de la mémoire après un long fonctionnement

Autrement dit, l’externalisation et le développement sur mesure d’une application Windows ne se limitent pas à « construire de nouveaux écrans ». Il faut les considérer comme un travail englobant l’investigation des actifs existants, la révision, le remplacement, l’intégration d’équipements, le déploiement, la maintenance et l’investigation des incidents.

Cet article résume, du point de vue du client, les points à clarifier avant de confier l’externalisation ou le développement sur mesure d’une application Windows.

Les domaines les plus souvent confiés aux prestataires de développement d’applications Windows

1. Développement d’une nouvelle application métier

Il s’agit des cas où des écrans de saisie, des écrans de recherche, des sorties de rapports, une intégration CSV, une intégration de fichiers et une intégration avec des systèmes externes soutenant les opérations internes sont construits sous forme d’application Windows.

Les raisons de choisir une application Windows plutôt qu’une application web se résument généralement à ceci :

• Vous avez besoin d’une gestion fine des fichiers et dossiers sur le PC local
• Vous souhaitez intégrer des périphériques USB, des instruments de mesure, des automates (PLC) ou des caméras
• Vous devez l’utiliser dans des environnements hors ligne ou des réseaux fermés
• Vous souhaitez exploiter des actifs Excel, VBA, COM et DLL existants
• Vous avez besoin d’un clavier, d’un lecteur de codes-barres ou d’un écran tactile sur les postes de terrain
• Vous avez besoin d’une surveillance résidente ou d’un traitement en arrière-plan

Même pour un nouveau développement, décider dès le départ si cela doit être une application Windows, si une application web suffirait, ou si seule une partie doit rester du côté Windows, réduira les retours en arrière ultérieurs.

2. Révision et maintenance d’un logiciel Windows existant

Dans les demandes d’externalisation et de développement sur mesure, la révision et la maintenance d’un logiciel existant sont plus fréquentes qu’un développement entièrement nouveau.

Par exemple, des situations comme celles-ci :

• Le code source existe, mais personne ne sait comment le compiler
• Il ne s’ouvre qu’avec une ancienne version de Visual Studio
• Il est resté bloqué sur VB6, MFC, WinForms ou .NET Framework
• Le responsable a quitté l’entreprise et personne ne connaît les spécifications
• Le fonctionnement est devenu instable après une mise à jour Windows ou un changement de PC
• Des partenaires ou le terrain demandent de nouvelles fonctionnalités

Dans ces cas, plutôt que de reconstruire immédiatement, nous commençons par un état des lieux :

• Quelle activité métier l’application soutient-elle ?
• Quelles fonctionnalités sont indispensables ?
• Dans quel environnement fonctionne-t-elle ?
• De quels équipements externes, DLL, bases de données et dossiers partagés dépend-elle ?
• Des journaux et des informations d’erreur sont-ils conservés ?
• Le code source, les instructions de compilation, le programme d’installation et les fichiers de configuration existent-ils encore ?

Le simple fait qu’un logiciel existant fonctionne constitue en soi une valeur. C’est pourquoi, dans le développement sur mesure, plutôt que de « tout jeter et reconstruire », une approche progressive devient importante : conserver, encapsuler ou remplacer.

Si COM / ActiveX / OCX est en jeu, commencez par clarifier la terminologie avec Une explication complète des différences entre COM, ActiveX et OCX, puis envisagez la stratégie de migration à l’aide de perspectives telles que le Tableau de décision « conserver / encapsuler / remplacer » pour ActiveX/OCX pour avancer plus facilement.

3. Applications d’intégration d’équipements et de matériel externe

Dans l’industrie manufacturière, le contrôle, la mesure, le domaine médical connexe et la recherche, les applications Windows sont souvent connectées à du matériel externe.

Les cibles d’intégration typiques sont les suivantes :

• Périphériques de communication série
• Périphériques USB
• Caméras industrielles
• Automates (PLC)
• Instruments de mesure
• Lecteurs de codes-barres
• Dossiers partagés et NAS
• DLL natives existantes
• SDK fournis par les fabricants

Dans ce domaine, il ne suffit pas de construire des écrans : il faut aussi concevoir la façon dont la communication se coupe, la reconnexion, les délais d’expiration, la journalisation, l’enregistrement des données brutes et l’affichage d’état.

La communication série en particulier tend à poser des problèmes au niveau des unités de réception, des délais d’expiration, de la reconnexion et du gel de l’interface. Il est donc prudent d’intégrer dès le départ des perspectives telles que Les pièges du développement d’applications de communication série.

De plus, l’état d’un équipement externe est parfois insuffisamment décrit par « connecté » ou « non connecté » seulement. Si vous distinguez la présence de l’équipement, sa réactivité, la disponibilité de ses fonctions, la fraîcheur des données et la cohérence de la configuration, vous obtenez un écran moins susceptible d’être mal interprété sur le terrain. Pour en savoir plus, voir Concevoir l’affichage de l’état des équipements externes.

4. Investigation de bugs et analyse des causes

Dans le développement sur mesure d’applications Windows, une investigation de bug est parfois nécessaire avant même tout travail de fonctionnalité.

Voici des demandes fréquentes :

• L’application plante seulement quelques fois par jour
• La mémoire continue de croître après un long fonctionnement
• Elle ne fonctionne pas uniquement sur un PC spécifique
• La communication avec un équipement s’interrompt pendant quelques secondes
• Des données sont perdues lors de l’intégration de fichiers
• Personne ne connaît les étapes de reproduction
• Les journaux sont trop pauvres pour tracer la cause

Ce type de problème ne se résout pas simplement en regardant le code. Il faut d’abord concevoir des points d’observation, puis collecter journaux, dumps de plantage, journaux de communication, journaux d’événements, utilisation mémoire, nombre de handles, etc.

Pour l’investigation des plantages, la clé est de savoir comment conserver les preuves au moment même du plantage, comme décrit dans Comment journaliser les plantages d’une application Windows et Introduction à la collecte de dumps de plantage (WER/ProcDump/WinDbg).

Pour une mémoire qui augmente, il faut distinguer s’il s’agit simplement d’une attente du GC ou d’une véritable fuite mémoire. Pour les applications .NET, suivez la démarche « observer, comparer, prouver » décrite dans Distinguer l’attente du GC d’une fuite mémoire en .NET.

5. Déploiement, signature et mises à jour automatiques

Après avoir terminé une application Windows, les équipes butent souvent sur la question de « comment la distribuer ».

• Faut-il créer un programme d’installation ?
• Ou simplement déposer les fichiers pour qu’ils fonctionnent tels quels ?
• Les utilisateurs standard peuvent-ils l’installer ?
• Des droits administrateur sont-ils nécessaires ?
• La distribution se fait-elle via un partage de fichiers interne ?
• Les utilisateurs doivent-ils la télécharger depuis le web ?
• Faut-il des mises à jour automatiques ?
• Comment gérer le certificat de signature de code ?
• Comment expliquer et gérer les avertissements SmartScreen ?

Les méthodes de déploiement incluent MSI, MSIX, ClickOnce, xcopy et des updaters personnalisés. Le choix ne doit pas se baser sur « ce qui est le plus simple », mais sur ce qui est enregistré auprès de l’OS et qui assume la responsabilité des mises à jour. Pour en savoir plus, voir le Guide de sélection des méthodes de déploiement d’applications Windows.

Pour une application Windows .NET interne que vous souhaitez distribuer à des utilisateurs standard avec des mises à jour automatiques légères, voir Introduction à ClickOnce : déploiement, mises à jour et critères de sélection.

En revanche, la distribution web ou externe soulève des problèmes d’avertissements SmartScreen et de signature de code. La raison pour laquelle le message « Windows a protégé votre PC » s’affiche est résumée dans Pourquoi Windows affiche « Windows a protégé votre PC ».

Cinq points à clarifier avant de confier l’externalisation ou le développement sur mesure d’une application Windows

1. Ce qui ne doit pas s’arrêter

La première chose à clarifier n’est pas une liste de fonctionnalités, mais « les activités métier qui ne doivent pas s’arrêter ».

• Le traitement des commandes s’arrête
• La ligne de contrôle s’arrête
• Les rapports ne peuvent plus être produits
• La communication avec l’équipement s’interrompt
• Le personnel de terrain revient au travail manuel
• Les audits et les traces ne sont plus conservés

Dans le développement sur mesure, la conception ne se limite pas à construire des écrans et des fonctionnalités : elle doit aussi garantir que l’activité ne s’arrête pas. Une fois ces priorités claires, il devient beaucoup plus facile de déterminer quelles fonctionnalités construire, lesquelles reporter et quels bugs investiguer en premier.

2. L’application actuelle et son environnement

Lors de la révision ou de la maintenance d’une application existante, on vérifie non seulement l’application elle-même, mais aussi son environnement.

Voici les informations qu’il vaut la peine de clarifier :

• Nom de l’application, objectif et services utilisateurs
• Nombre d’utilisateurs et nombre de postes
• Versions de Windows
• 32 bits / 64 bits
• Versions de .NET Framework / .NET
• Version de Visual Studio
• Bases de données, dossiers partagés, API externes
• Équipements, DLL, SDK intégrés
• Procédure d’installation
• Emplacement des fichiers de configuration
• Emplacement des journaux
• Présence ou non du code source
• Présence ou non d’instructions de compilation
• Présence ou non de documents laissés par le prédécesseur

Plus ces informations sont disponibles, plus les devis et les investigations gagnent en précision. À l’inverse, si les informations manquent, il est plus prudent de faire de la première phase un « état des lieux » distinct.

3. Nouveau développement, révision ou remplacement ?

Dans les demandes concernant des applications Windows, il vaut souvent mieux ne pas décider dès le départ de « tout reconstruire ».

La question de savoir s’il faut continuer à utiliser une application .NET Framework ou migrer vers .NET dépend du type d’application, des bibliothèques dépendantes, de l’intégration COM et de la méthode de déploiement. Faire d’abord l’état des lieux des points à vérifier, comme dans la Liste de contrôle avant migration de .NET Framework vers .NET, facilite grandement la décision.

4. Déploiement, mises à jour et privilèges

Pour les applications Windows, c’est parfois le déploiement, plus que le développement, qui pose problème.

Les points particulièrement à vérifier sont les suivants :

• Sera-t-elle utilisée par des utilisateurs standard ?
• Existe-t-il des opérations nécessitant des droits administrateur ?
• Installation pour tous les utilisateurs ou par utilisateur suffisant ?
• Usage interne uniquement ou distribution externe également ?
• Des mises à jour automatiques sont-elles nécessaires ?
• Y a-t-il des postes hors ligne ?
• La signature de code est-elle requise ?
• Faut-il tenir compte de Microsoft Defender SmartScreen ?
• Existe-t-il des politiques de gestion comme Intune, GPO ou App Control ?

Séparer les opérations nécessitant des droits administrateur de celles qui n’en ont pas besoin améliore à la fois la sécurité et l’ergonomie au quotidien. La frontière des privilèges peut être vérifiée à l’aide de perspectives telles que Quand les droits administrateur Windows sont nécessaires, et quand ils ne le sont pas.

5. Facilité de maintenance

Ce qui compte dans le développement sur mesure n’est pas seulement que l’application fonctionne au moment de la livraison. On souhaite qu’elle reste, des années plus tard, dans un état permettant à une autre personne responsable de l’investiguer, de la réviser et de la redéployer.

Les applications Windows faciles à maintenir présentent les caractéristiques suivantes :

• Les instructions de compilation sont conservées
• Les bibliothèques dépendantes et leurs versions sont connues
• L’emplacement et la signification des fichiers de configuration sont connus
• Les journaux sont émis avec une granularité utile pour l’investigation
• Des preuves sont conservées en cas de plantage
• Il existe des procédures de déploiement et de retour en arrière
• Les responsabilités du code source sont clairement séparées
• Les opérations nécessitant des droits administrateur sont limitées
• Les informations secrètes ne sont pas stockées en clair

Pour la vérification de sécurité minimale avant mise en production, vérifiez les privilèges, la signature, les informations secrètes, la communication, les entrées, les DLL et la journalisation, comme dans la Liste de contrôle de sécurité des applications Windows.

Si des mots de passe ou des jetons sont stockés dans des fichiers de configuration, il faut éviter le stockage en clair et concevoir une protection à l’aide des mécanismes de Windows. Pour en savoir plus, voir Comment stocker en toute sécurité les informations confidentielles d’un fichier de configuration.

Décisions technologiques fréquentes pour les applications Windows

Choisir entre WinForms, WPF et WinUI

Pour le développement d’une nouvelle application Windows, le choix entre WinForms, WPF et WinUI revient souvent en question.

En comparaison rapide, cela donne ceci :

Cependant, la technologie la plus récente n’est pas toujours la bonne réponse. Le choix doit prendre en compte l’expérience de l’équipe existante, l’horizon de maintenance, la méthode de déploiement, les exigences d’écran et les bibliothèques associées.

Pour en savoir plus, voir le tableau de décision dans le Guide de sélection WinForms/WPF/WinUI.

C# / .NET suffit-il, ou faut-il du C++ ou des DLL natives ?

La plupart des applications métier peuvent être entièrement construites en C# / .NET. Cependant, dans des cas comme ceux-ci, on envisage parfois le C++, des DLL natives, P/Invoke, C++/CLI ou COM :

• Le SDK du fournisseur cible le C/C++
• Vous devez appeler des DLL existantes
• Il y a un traitement d’image ou un contrôle de dispositif à haute vitesse
• Vous devez utiliser des actifs COM existants
• Vous devez franchir la frontière 32 bits / 64 bits

Dans ce type de projet, il faut clarifier non seulement la facilité de construction de l’interface, mais aussi les frontières de processus, la propriété mémoire, les exceptions, le threading et la bitness.

Application Windows ou application web ?

Nous recevons aussi des demandes comme « nous voulons transformer une vieille application Windows en application web ». Passer au web est parfois la bonne solution, mais tout ne doit pas nécessairement devenir une application web.

Les applications Windows sont adaptées, par exemple, dans les cas suivants :

• Connexion directe à un équipement ou à du matériel local
• Utilisation hors ligne
• Traitement de gros fichiers locaux
• Utilisation d’actifs COM / DLL / VBA existants
• Fonctionnement rapide requis sur les postes de terrain
• Surveillance résidente et traitement en arrière-plan

D’un autre côté, si plusieurs sites doivent consulter les mêmes données, si vous souhaitez une utilisation uniquement via navigateur, ou si vous voulez réduire la gestion des postes, le passage au web ou au cloud peut être plus adapté.

Sur le terrain, plutôt que de tout basculer d’un coup vers le web, il existe aussi des architectures qui ne conservent que les parties nécessitant réellement une application Windows, tout en confiant la gestion et la consultation des données au côté web.

Le déroulement du développement sur mesure

Voici comment mener en toute sécurité l’externalisation et le développement sur mesure d’une application Windows.

1. État des lieux

On clarifie d’abord l’activité métier cible, l’environnement d’utilisation, l’application existante, le matériel externe, la méthode de déploiement et les symptômes problématiques.

Si une application existante est présente, on vérifie le code source, l’environnement de compilation, les fichiers de configuration, les journaux, le programme d’installation et les documents associés.

2. Conception des points d’observation

En cas de bug ou d’instabilité, on rend d’abord la cause traçable avant de se lancer dans les corrections :

• Ajouter de la journalisation
• Capturer des dumps de plantage
• Conserver les journaux de communication
• Enregistrer la mémoire et le nombre de handles
• Conserver l’historique des opérations
• Sauvegarder des captures d’écran et l’état au moment d’une anomalie

Plus un problème est difficile à reproduire, plus la conception des points d’observation porte ses fruits.

3. Décision de l’approche

Après avoir observé l’état actuel, on décide de l’approche : révision, prolongation, migration progressive, remplacement complet ou investigation uniquement.

À ce stade, on décide aussi du choix technologique, de la méthode de déploiement, de la méthode de mise à jour et du périmètre de maintenance.

4. Implémentation et tests

Lors de l’implémentation, on développe séparément les écrans, la logique métier, l’intégration des équipements externes, l’intégration de fichiers, la gestion des erreurs, la journalisation, la configuration et le déploiement.

Lors des tests, on vérifie non seulement les scénarios normaux, mais aussi les scénarios anormaux :

• L’équipement n’est pas connecté
• La communication se coupe en cours de route
• Un fichier est verrouillé
• Les privilèges sont insuffisants
• Le réseau est instable
• La configuration est corrompue
• Une mise à jour échoue
• L’application se termine anormalement

5. Déploiement et migration

Une fois terminé, on prépare les procédures de déploiement, de mise à jour, de retour en arrière, la configuration initiale et les explications destinées aux utilisateurs.

En cas de migration depuis une application existante, on intègre au plan le fonctionnement parallèle ancien/nouveau, le retour arrière, la migration de données et la formation des utilisateurs.

6. Maintenance et amélioration

Après la livraison, on améliore l’application pour l’adapter à l’exploitation, en observant les journaux et le contenu des demandes.

Les applications Windows sont affectées par les mises à jour de l’OS, les remplacements de PC, les changements de matériel périphérique et les changements de politique de sécurité. C’est pourquoi une conception et une documentation pensées pour la maintenance sont indispensables.

Informations utiles à préparer avant un devis

Tout ne doit pas nécessairement être disponible au moment de la consultation. Cependant, disposer des informations suivantes accélère les échanges :

• L’objectif de l’application
• Ce qui pose problème actuellement
• Nombre d’utilisateurs et de postes
• Versions de Windows
• Présence ou non d’une application existante
• Présence ou non du code source
• Langage de développement et framework
• Équipements, bases de données, fichiers, API intégrés
• Écrans d’erreur et journaux
• Étapes de reproduction
• Délai de livraison souhaité
• Activités métier qui ne doivent absolument pas s’arrêter
• Distribution interne ou externe
• Besoin de maintenance également

Il n’y a aucun problème si certains points restent inconnus. Clarifier ce qui est connu et ce qui ne l’est pas constitue en soi le premier travail du développement sur mesure.

En résumé

Lorsque vous confiez l’externalisation ou le développement sur mesure d’une application Windows, dire simplement « développez-nous une application » rend le périmètre nécessaire difficile à cerner.

Voici les 7 points à clarifier avant de vous lancer :

• Nouveau développement, révision de l’existant ou remplacement ?
• Quelles activités métier ne doivent pas s’arrêter ?
• Existe-t-il des actifs existants, du matériel externe, des DLL, COM ou ActiveX ?
• Choix technologique : WinForms, WPF, WinUI, migration .NET, etc.
• Comment gérer le déploiement, la signature, les mises à jour automatiques et les droits administrateur ?
• Conception de l’investigation pour les journaux, dumps de plantage, mémoire et communication
• Comment laisser l’application dans un état maintenable après la livraison ?

Les applications Windows sont étroitement liées aux activités de terrain, aux équipements, aux fichiers, au matériel périphérique et aux contraintes du système d’exploitation Windows. C’est justement pour cela que, dans l’externalisation et le développement sur mesure, il est essentiel de concevoir non seulement pour « construire », mais aussi pour « investiguer », « corriger », « documenter », « distribuer » et « exploiter ».

Si vous êtes confronté à des difficultés liées à l’externalisation ou au développement sur mesure d’une application Windows, à un nouveau développement, à la révision et à la maintenance d’un logiciel existant, à l’intégration d’équipements, à l’investigation de bugs ou à la conception du déploiement et des mises à jour, commencez par nous consulter pour clarifier votre situation actuelle.

Nous consulter sur le développement d’applications Windows

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.

Pouvons-nous vous consulter même sans le code source ?

Oui, c'est possible. Cependant, sans code source, ce que nous pouvons faire est limité. Dans certains cas, une investigation reste possible à partir de la configuration, de l'environnement, des journaux, des dépendances externes, des exécutables, des programmes d'installation et du contenu des communications. En revanche, l'ajout de fonctionnalités ou des corrections en profondeur nécessitent souvent le code source ; il est donc réaliste de commencer par un état des lieux.

Pouvons-nous vous consulter pour une application contenant du vieux VB6, VBA, COM ou ActiveX ?

Oui, c'est possible. Dans ce domaine, plutôt que de tout remplacer d'un coup, il est important de distinguer ce qu'il faut conserver, ce qu'il faut encapsuler et ce qu'il faut remplacer. En particulier, les actifs qui fonctionnent encore en production sont plus sûrs à migrer progressivement, en surveillant les risques.

Faut-il remplacer notre application Windows par une application web ?

Cela dépend de l'objectif. Les applications web conviennent pour plusieurs sites, une gestion simplifiée des postes et un usage via navigateur. En revanche, s'il y a intégration d'équipements, traitement de fichiers locaux, fonctionnement hors ligne ou utilisation de DLL existantes, conserver une application Windows peut être plus naturel. Plutôt que de tout basculer vers le web, répartir les responsabilités entre le côté Windows et le côté web est aussi une option.

Pouvons-nous vous confier uniquement une investigation de bug ?

Oui, c'est possible. Pour les plantages après un long fonctionnement, les interruptions de communication, la croissance de la mémoire ou les défaillances propres à certains postes, il est important de commencer par rendre la cause traçable plutôt que de modifier immédiatement le code. Nous organisons les journaux et les dumps, réduisons les conditions de reproduction, puis décidons de la stratégie de correction.

Pouvez-vous développer des applications nécessitant des droits administrateur ?

Oui, mais une conception qui s'exécute en permanence avec des droits administrateur doit être étudiée avec prudence. Il est plus sûr d'exécuter la partie quotidienne avec un compte utilisateur standard et d'isoler uniquement les opérations qui nécessitent une élévation. Pour l'installation, l'enregistrement de services, l'écriture dans des zones protégées, les pilotes et les paramètres pour tous les utilisateurs, nous clarifions d'abord la conception des privilèges.

Pouvez-vous développer sur mesure de petites applications Windows internes ?

Oui. Même pour de petites applications, anticiper le déploiement, les mises à jour, la journalisation, la configuration, les sauvegardes et la transmission entre responsables les rend plus faciles à utiliser sur le long terme. En particulier, les petites améliorations métier comme l'automatisation de tâches Excel, la conversion CSV, la surveillance de fichiers, la sortie de rapports ou la collecte de données d'équipements se prêtent souvent bien aux applications Windows.

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.