Bonjour,
 
j'envisage de me lancer dans un projet perso, mais malheureusement ça fait 5 ans que je ne me suis plus intéressé aux techno de développement. Je viens donc ici dans l'espoir d'obtenir des pistes sur ce qui se fait de mieux aujourd'hui pour répondre à mes besoins. Perso j'ai surtout fait du Java/MySQL ou Oracle et du C#/SQL Server, mais les choses ont ptete bougées depuis le temps.
 
Il me faudrait des technos gratuites, même dans le cadre d'une exploitation commerciale, et pérennes.
 
Niveau volume de données ce sera pas énorme, de l'ordre de dizaines de milliers d'items composés de types basiques pour la grande majorité (texte / nombre).
Ces données doivent être exploitables sur un poste de travail standard en local, mais aussi au travers d'un navigateur lorsqu'elles seront manipulées à distance. Peut-être cela vaut-il donc la peine aujourd'hui que je me penche sur une appli unique utilisable au travers d'un navigateur même lorsqu'elle sera utilisée en local ?
 
Par contre, il y a également une problématique de synchronisation des données. En effet, les données accédées en local et celles accédées à distance doivent être cohérentes, mais ne doivent pas être hébergées sur la même machine. Concrètement, l'appli doit être utilisable sur plusieurs postes en réseau local avec ou sans connexion internet de disponible, et doit également être utilisable sur n'importe quel autre poste ayant une connexion internet. Le cas nominal étant que les postes en réseau local aient un accès internet, indispensable pour une synchronisation des données efficaces. Par contre, ces postes doivent également être opérationnel en cas de coupure internet, et il faudra donc gérer les conflits potentiels une fois qu'ils seront reconnectés.
 
Merci d'avance pour vos conseils

Je pense que ce qui va poser le plus de pb, c'est le fait que l'appli puisse fonctionner en local dans connexion : ça élimine de fait tous les langages web côté serveur (php, asp...). Ca te laisse donc le java, C#, Delphi par ex.
La synchro entre différentes BD va aussi te poser des difficultés Histoire de bien cerner le pb, pourquoi ce besoin ?

Merci de ta réponse
 
Plus je regarde, et plus je me dis qu'effectivement j'ai tout intérêt à rester sur un couple java/postgre. Mais ceci dit, le principe du local sans connexion n'élimine pas tous les langages web côté serveur, à condition que l'installation, l'utilisation et la maintenance du serveur en question soit facile. Au niveau SQL, c'est le cas du serveur postgre par exemple.
L'intérêt que j'aurai vu dans une solution unique client/serveur c'est que je n'aurai pas eu à refaire le boulot pour l'utilisation à distance. Néanmoins, j'ai tout de même l'impression que l'offre actuelle ne comble pas encore toutes les possibilités offertes par un client lourd, notamment en terme d'ergo et de réactivité.
 
Au niveau de la synchro des BD, ça satisferait plusieurs besoins :
- sauvegarde des données dans un autre lieu physique et possibilité de basculer rapidement sur la base distante si la base locale plante / crame
- possibilité d'utiliser le système en cas de coupure internet
- accès ponctuel extérieur possible sans que ce soit trop pénalisant en terme de performance dans le cadre de l'utilisation principale en local

Oui, mais une appli en local, ça veut dire qu'en terme de déploiement, faut l'installer sur chaque poste alors qu'une appli centralisée, tu mets à jour le serveur et c'est tout.
Et une appli centralisée peut tout à fait avoir une redondance sur un autre serveur où le code de l'appli et la BD serait synchrone.

Oui, c'est bien pour ça que je me penchais sur les applis centralisées . D'autant plus que je me doutait qu'on commençait à faire pas mal de truc avec les scripts exécutés côté client, mais au final comme j'ai dit, j'ai l'impression qu'on perd trop en ergonomie avec ce genre de solution en comparaison d'un client lourd. D'un côté j'ai peur que ce soit moins intuitif et trop déroutant par rapport à une appli standard, d'un autre côté la démocratisation des trucs genre google doc me laisse penser le contraire.

Franchement, des applis web en php côté serveur et avec du JS+Ajax côté client, n'ont rien à envoyer côté ergonomie par rapport à une appli client lourd Je dirais même qu'une appli web pourrait être plus ergonomique car avec le css  et le JS, tu peux faire des choses qu'en client lourd, ça peut être plus dur à implémenter...

J'ai continué à regarder, et y a quand même pas mal de choses avec lesquelles je suis pas familier qui me font un peu peur d'un point de vue utilisateur. Rien que l'installation et la configuration d'un serveur d'app, j'ai peur qu'un utilisateur lambda puisse vite y foutre le boxon dans le cadre d'une utilisation quotidienne de sa machine. Après y a l'exposition du code aussi, et les problèmes éventuels de sécurité qui vont avec.
Je dis pas que ce sont des problèmes insurmontables, mais vu mes compétences nulles en la matière, je pense que cela reviendrai à me mettre beaucoup de batons dans les roues pour un avantage pas significatif que ça : l'appli ne sera jamais vouée à être utilisée sur plus d'une dizaine de poste par infrastructure, et pour ce qui est de l'utilisation à distance, ce sera de toute façon dans un cadre parfois différent de fonctionnalité et nécessitera probablement un traitement à part.

L'appli web conserve malgré tout l'avantage de fonctionné à distance, que ça soit en interne de l'entreprise ou à l'extérieur. Et y'a que le serveur à mettre à jour au lieu des postes clients. C'est pas un hasard si la plupart des nouvelles applis d'entreprises sont majoritairement de type web
 
Par rapport au pb de coupure de connexion réseau, je pense qu'il vaudrait mieux travailler sur une solution à "comment faire pour diminuer ce risque ou avoir une connexion de secours" plutôt que de partir sur une appli décentralisée avec des synchros à faire et trouver une solution complémentaire pour les accès distants. Parce que là, tu vas vite te retrouver avec une solution bancale et compliquée à faire fonctionner de manière stable et à maintenir...

Oui, mais les applis entreprise sont déployées là où il y a les infrastructures pour les accueillir, rarement chez l'artisant ou les pme localisé dans des coins paumés.
 
Et malheureusement, je maintiens que mon appli doit pouvoir tourner en local, il y a de fortes contraintes de réactivité qui ne sont pas conciliable avec un fonctionnement pur web . Après, on peut toujours installer un serveur en local, mais j'ai peur que ça complique pas mal le dev, l'install et la maintenance, pour un gain pas forcément énorme. En effet, il n'y a que la base de données que je vais devoir rendre accessible de l’extérieur, et postgre propose plusieurs mécanismes de réplication.
 
Du coup pour l'instant je partirai sur du JavaFX/EclipseLink-JPA/Postgre.

"fortes contraintes de réactivité qui ne sont pas conciliable avec un fonctionnement pur web" -> Tu peux développer, svp ?

bah ça doit marcher du tac'o tac quoi, zéro latence sensible.

Quelle genre d'appli de gestion nécessite une telle réactivité ? Tu travailles dans la finance ?

Oui, dans la finance mais pour les banques artisanales ou pme
 
Non, en vrai c'est une appli métier qui doit pour certain process autoriser des traitements à la chaîne très très rapide. C'est pas une question de vie ou de mort, mais autrement ça rendrait la tâche très pénible.

Tu sais qu'il existe des solutions pour masquer la latence :  
- faire des batch qui se lancent périodiquement pour calculer des trucs qui prendrait trop de temps à faire en direct
- mixer les technos : par ex, un script php qui appelle un binaire (.exe) codé en C/C++ pour réaliser une partie d'un traitement lourd parce que le C/C++ sera plus rapide que php
- ...
 
Edit : et je parle même pas de la mise en cache de pages web pour qu'elles soient servies plus vite, du load balancing, de l'utilisation d'APC ou de memcached pour accélérer php, du tuning du fichier de conf de mysql pour utiliser plus les buffers et mises en caches de requêtes, l'utilisation de procédures stockées pour accélérer certains traitements en BD...
 
Si Facebook, qui utilise php, arrive à soutenir la charge/réactivité, je pense que ton appli devrait y arriver aussi

Ah non, mais y a zéro charge sur l'appli, en gros t'as 5 utilisateurs max en même temps. Par contre, pour le coup facebook c'est pas suffisamment réactif. J'ai des actions utilisateurs impliquant une modification des données qui idéalement doivent pouvoir s’enchaîner de manière atomique sans latence aucune. De plus ces actions sont difficiles à anticipées car elles sont liées à du scan d'objet physique sans ordre logique. Une appli exclusivement web rajouterait fatalement ces millisecondes super relou je pense, ou bien on perdrait l'atomicité.

J'ai un peu de mal à comprendre ce que doit faire ton appli Actuellement, tu trouves des applis web de modélisation d'objets 3D (à base html5/js ou de WebGL) qui marchent bien...

Je me doute que c'est pas évident vu le peu de détails que je donne .
 
Mais pour le coup, quand je parlais du scan d'objet physique, c'était du scan de code barre en gros, ou autre système d'identification unique. Donc ce sont des opérations extrêmement rapide : click - click - click, t'as scanné trois objets et les traitements ont été fait pour chacun d'entre eux de façon unitaire et atomique.

Ben si t'as une liaison réseau digne de ce nom et un serveur correct, ça peut tout à faire être très rapide
Ajax a beaucoup amélioré les possibilités et l'ergonomie des applis web
 
Edit : pour mon appli web Astres (cf ma signature), le serveur sur lequel elle tourne est capable de traiter environ 80 requêtes SQL par seconde.

Ouais non c'est clair que si c'est du client/serveur en réseau local ça le fait carrément .

Bonjour, c'est marrant de voir ce topic parce qu'avec un pote on vient justement de lancer un site pour résoudre ce genre de question http://forum.hardware.fr/hfr/Progr [...] 2309_1.htm
N’hésitez pas à me dire ce que vous en pensez!

J'ai regardé rapidement ton site : c'est quand même très éloigné de son pb. J'ai rien trouvé sur ton site qui puisse répondre à sa question.

Bonjour, tout d'abord merci d'avoir visité mon site
C'est vrai qu'il ne répond pas à son problème précis. Mais son objectif est justement de guider les gens qui cherchent les bonnes pratiques, méthodes, outils, ...
 
Au fait, est ce que tu as des remarques par rapport à mon site?
Merci d'avance

Je suis du même avis. J'ai failli sanctionner, mais au vu de ses autres interventions sur le forum, j'ai estimé qu'on pouvait appliquer les consignes de justice hyper-laxiste telles que préconisées par la ministre actuellement en poste...
A+,