Service
Développement d'applications de bureau sur mesure
Pour le travail qu'un onglet de navigateur fait mal.
Le poste de bureau est un choix délibéré, pas un héritage. Il est justifié quand la tâche est une saisie clavier à fort volume, quand du matériel local entre en jeu — balances, imprimantes, scanners, lecteurs biométriques — ou quand le logiciel doit continuer de fonctionner internet coupé. Construit pour Windows, là où ce travail se fait réellement.
La décision
Quand c'est le bon choix.
Presque tout est passé au navigateur, et c'est le plus souvent la bonne chose. Trois usages n'ont pas bien suivi. Le premier est la saisie intensive au clavier : un opérateur qui enregistre quatre cents pièces par jour a besoin d'un ordre de tabulation, de raccourcis clavier et d'une réponse immédiate qu'un formulaire web atteint rarement.
Le deuxième, c'est le matériel. Balances, imprimantes d'étiquettes et matricielles, douchettes en mode clavier, lecteurs biométriques, périphériques sur port COM. L'accès depuis le navigateur y est soit impossible, soit assez fragile pour devenir l'essentiel du travail du support.
Le troisième, c'est le fonctionnement sans réseau. Un comptoir qui ne peut pas facturer quand la connexion tombe est un comptoir à l'arrêt, et pour beaucoup d'entreprises ce n'est pas une panne acceptable. Une application de bureau avec des données locales et une synchronisation en arrière-plan, elle, continue simplement.
Ce que vous obtenez
Ce que couvre la mission.
Saisie pilotée au clavier
Ordre de tabulation, raccourcis et validation sur place, pensés pour quelqu'un qui ne touche jamais la souris et connaît le formulaire par cœur.
Matériel local
Balances, imprimantes d'étiquettes, facturation matricielle, scanners et lecteurs biométriques, pilotés directement plutôt que via une couche navigateur.
Fonctionnement sans réseau
Une base de données locale comme espace de travail, avec synchronisation vers le serveur quand il est joignable et une règle de conflit claire quand il ne l'est pas.
Synchronisation multi-sites
Des sites qui fonctionnent de façon autonome et se réconcilient au central, sans lien permanent avec le siège.
Arithmétique exacte
L'argent en décimal à virgule fixe partout. La virgule flottante dans un système de facturation est un litige d'arrondi qui attend d'être trouvé.
Mises à jour gérées
Des mises à jour signées et versionnées, livrées et appliquées sans qu'un technicien passe sur chaque poste.
Stack
Avec quoi nous le construisons.
Choisis projet par projet. Rien n'est imposé par défaut ici, et l'équipe qui assurera la maintenance pèse autant que le problème.
Application
.NET avec WPF ou WinUI pour Windows, choisis pour l'accès matériel et la maturité du déploiement plutôt que par mode.
Données locales
SQLite ou SQL Server LocalDB, avec un chemin de migration qui survit à un changement de schéma sur un poste hors ligne.
Synchronisation
Une API partagée avec la plateforme web, pour que les clients de bureau et navigateur ne divergent pas dans leurs règles métier.
Matériel
Port série, USB HID et SDK constructeurs, testés sur les appareils réellement présents chez vous.
Déploiement
Des installeurs signés avec mise à jour automatique et un retour arrière qui fonctionne.
Comparaison
Navigateur ou client de bureau.
Le poste de bureau est un choix délibéré pour un ensemble restreint de tâches. Voici où chacun l'emporte réellement.
| Critère | Navigateur | Client de bureau |
|---|---|---|
| Déploiement | Rien à installer ; tout le monde est immédiatement sur la version courante | Un installeur signé avec mise à jour automatique et un retour arrière qui marche |
| Saisie clavier intensive | Possible, mais rarement aussi rapide qu'un opérateur qui connaît le formulaire par cœur | Ordre de tabulation, raccourcis et réponse immédiate, pensés pour qui saisit quatre cents pièces par jour |
| Matériel local | Balances, imprimantes matricielles et périphériques sur port COM : impossibles ou fragiles | Pilotés directement via les SDK constructeurs, le port série et l'USB HID |
| Travailler quand le réseau tombe | S'arrête, sauf à ajouter une ingénierie considérable | Continue sur les données locales et se réconcilie au retour du lien |
| Portée | N'importe quel appareil, partout, y compris les téléphones | Les postes sur lesquels vous l'installez, en général sous Windows |
| La bonne réponse pour | Direction, reporting, tout ce qui est multi-appareils ou à distance | Le comptoir, l'atelier, le poste de pesée |
Comment cela se déroule
De la première conversation à la mise en ligne.
Indicatif pour un travail de cette nature. Le pilote n'est pas optionnel — rien n'est basculé tant que les utilisateurs n'ont pas dit que cela tient.
- 1 semaine
Cadrage
Nous observons la saisie réelle et recensons chaque appareil à piloter. C'est cette liste d'appareils qui fait ou défait l'estimation.
- 4 à 7 semaines
Développement du socle
D'abord le chemin de saisie et l'intégration matérielle, testés sur les appareils présents chez vous et non sur des équivalents.
- 2 semaines
Pilote au comptoir
Un comptoir ou une machine tourne dessus pendant que le processus existant continue, jusqu'à ce que les opérateurs cessent de revenir vers l'ancien système.
- 1 à 3 semaines
Déploiement progressif
Les postes restants, la mise à jour automatique signée activée, et le chemin de synchronisation vers la plateforme web vérifié en coupant délibérément le réseau.
Après la mise en service
Ce qui change.
- L'opérateur cesse d'attendre l'écran, et sur une journée entière c'est tout l'argument en faveur du poste de bureau.
- Une coupure de connexion ne signifie plus un comptoir à l'arrêt.
- Le matériel qui était piloté à la main, ou pas du tout, entre dans l'enregistrement.
- Les mises à jour atteignent chaque poste sans qu'un technicien se déplace partout.
Décrit qualitativement à dessein. Nous ne publions pas de pourcentages d'amélioration que nous ne pouvons pas rattacher à un client nommé, avec son accord.
Questions
Questions fréquentes.
Les logiciels de bureau ne sont-ils pas dépassés ?
Pour la plupart des applications oui, et nous recommanderons le web. Le poste de bureau reste la bonne réponse pour la saisie intensive, le matériel local et le fonctionnement sans réseau. Le choisir pour ces raisons est une décision d'ingénierie, pas un héritage.
Peut-il fonctionner aussi avec notre système web ?
Oui, et c'est en général souhaitable. Le schéma courant est un client de bureau au comptoir ou en atelier et un navigateur pour la direction, tous deux sur la même API, afin que les règles ne divergent pas.
Et macOS ou Linux ?
C'est possible et cela mérite d'en parler. L'essentiel de la demande porte sur Windows, parce que c'est là que se trouvent les pilotes matériels et le parc existant.
Comment les mises à jour sont-elles gérées ?
Les mises à jour signées arrivent automatiquement et s'appliquent au redémarrage, la version est visible dans l'application, et un retour arrière existe si une version se comporte mal.
L'application de bureau et le système web peuvent-ils partager une base de données ?
Ils devraient partager une API plutôt qu'une base de données. Deux clients qui écrivent directement dans les mêmes tables, c'est exactement ainsi que les règles métier divergent ; une API devant signifie que les règles ne peuvent pas différer entre le comptoir et le navigateur.
Que se passe-t-il si un poste est resté hors ligne une semaine ?
Il continue sur les données locales et se réconcilie à la reconnexion, selon une règle de conflit choisie pendant le cadrage plutôt que laissée à ce que le code fait par défaut. Tout ce qui est réellement ambigu est présenté à une personne au lieu d'être tranché en silence.