Discussion :

[Lucas Panny]

Bonjour,

Je parle de développer une application de gestion du travail d'une société utilisant un serveur central et une base de données (comme les banques)
D'après vos expériences et les nouvelles tendances, quel langage, EDI est le plus adapté?

Une tendance actuelle c'est de faire une application web (PHP si Apache, ASP si IIS) et tous les PC clients n'auront qu'à ouvrir leur navigateur! Il paraît que c'est plus lent qu'une application exécutable sur chaque client et le serveur car on va transiter toute une page

C++? Qt? Web (le problème avec PHP c'est que c'est OUVERT, l'admin connaît le code)? Java? Windev?

[souviron34]

euh..

sans vouloir faire de pub, mais des choses comme la suite IBM Rational, etc etc, .... ça fait ce que tu veux faire...

Et pour la gestion du code, des trucs comme cvs, svn, ClearQuest, etc, ça marche aussi...

[bretus]

Bonjour,

Une tendance actuelle c'est de faire une application web (PHP si Apache, ASP si IIS) et tous les PC clients n'auront qu'à ouvrir leur navigateur! Il paraît que c'est plus lent qu'une application exécutable sur chaque client et le serveur car on va transiter toute une page

Le gros avantage est là : tu n'as pas a demander à toute la boite de procéder à des installations.

Pour la lenteur, dans la mesure où tu ne fais pas de calcul scientifique coté serveur, php peut tenir la route. Les accès aux bases de données sont relativement efficaces, surtout si tu utilises Zend ou PEAR...

Pour ce qui est de faire transiter la totalité de la page, il existe des techniques plutôt simple à mettre en place pour l'éviter : AJAX ( note dans un coin Prototype.js ). Ce n'est pas un problème de technologie, c'est un problème de conception.

C++? Qt? Web (le problème avec PHP c'est que c'est OUVERT, l'admin connaît le code)? Java? Windev?

A mon avis, tu vas faire exploser tes temps de développement avec du C++ ou Java et tu auras du mal à faire évoluer ton application ( il te faudra déployer des versions etc... ). Rien ne t'empêche pour autant de concevoir l'aspect serveur de ton application, de sorte que le serveur se présente comme un service pour des clients lourds (WebService).

L'admin système connaît le code en PHP, sauf si tu passes par un outils qui le rend illisible. Mais à quoi bon lui cacher? C'est pas à mon avis le plus gros risque dans une application réseau...

Pour les outils propriétaires, comme le suggère souviron, si personne n'a les compétences de conception dans ta boite, je pense que ça peut être une bonne solution.
Le problème de ces solutions réside dans le fait qu'il est difficile, voir impossible de les faire évoluer soi même. Tu veux une extension, tu payes cher. Seulement, si personne ne conçoit convenablement, la solution perso n'est pas évolutive, tu veux une extension, tu y passes une semaine ou pire, tu casses tout...


Bon courage,

[Lucas Panny]

L'application WEB paraît être le plus rentable surtout le fait qu'il n'y a plus rien à installer sur les clients (browsers only), on n'a qu'à travailler sur le serveur

Laissez-vous moi énumérer quelques défauts:
- les langages interprétés web ne sont pas plus rapides que les langages compilés (C++, etc)
- transiter des pages web (présentation + données) est plus lourd que des données seulement, c'est vrai qu'AJAX est une amélioration

Le grand problème avec le client-serveur c'est que le temps à programmer devient plus LONG, le versionning est un cauchemar car il faut modifier toutes les applications sur tous les clients

Cacher le code source PHP, cela est-il possible?? Je projette de créer un interfaçage entre Apache et PHP pour coder mes fichiers. Je crains seulement un conflit avec la licence GNU-GPL car je pense vendre

[Franck SORIANO]

L'application WEB paraît être le plus rentable surtout le fait qu'il n'y a plus rien à installer sur les clients (browsers only), on n'a qu'à travailler sur le serveur

Tu as aussi des solutions de type TSE ou Citrix qui te permettront d'avoir le même fonctionnement en C/S.

Laissez-vous moi énumérer quelques défauts:
- les langages interprétés web ne sont pas plus rapides que les langages compilés (C++, etc)
- transiter des pages web (présentation + données) est plus lourd que des données seulement, c'est vrai qu'AJAX est une amélioration

J'ajouterais aussi qu'il est beaucoup plus difficile de créer une appli sécurisée en Web qu'en C/S : Rien ne te dis que les requêtes http reçues par le serveur sont bien issues de la page web que tu avais écrites.

Le grand problème avec le client-serveur c'est que le temps à programmer devient plus LONG

Ca ça dépend uniquement de tes compétences en dev. Je serais même plutôt tenté de dire que c'est le contraire.
En C/S, tu peux avoir des environnements RAD (genre Delphi) qui te permettront de coder facilement des IHM évoluées.

le versionning est un cauchemar car il faut modifier toutes les applications sur tous les clients

Heu... parce que tu crois qu'en Web sera différents ?
Le problème du versionning n'a rien à voir avec la techno que tu utilises. Si tu as plusieurs clients, que chacun possède son serveur avec une copie du site, tu peux être sûr que lorsque tu sortiras une mise à jour, tout tes clients ne migreront pas sur la nouvelle version instantannément.
Dès lors, tu devras gérer plusieurs versions en production... et c'est là que les choses comment à devenir compliquée.

Cacher le code source PHP, cela est-il possible??

Oui c'est possible.
Par exemple, il existe des solutions tiers (payantes) qui te permettront de crypter les sources PHP. Tes scripts PHP sont cryptés et il faut installer une extension PHP spéciale pour pouvoir les lires et les exécuter.

[chaplin]

+1

Heu... parce que tu crois qu'en Web sera différents ?
Le problème du versionning n'a rien à voir avec la techno que tu utilises. Si tu as plusieurs clients, que chacun possède son serveur avec une copie du site, tu peux être sûr que lorsque tu sortiras une mise à jour, tout tes clients ne migreront pas sur la nouvelle version instantannément.
Dès lors, tu devras gérer plusieurs versions en production... et c'est là que les choses comment à devenir compliquée.

[Mac LAK]

Le problème du versionning n'a rien à voir avec la techno que tu utilises. Si tu as plusieurs clients, que chacun possède son serveur avec une copie du site, tu peux être sûr que lorsque tu sortiras une mise à jour, tout tes clients ne migreront pas sur la nouvelle version instantannément.
Dès lors, tu devras gérer plusieurs versions en production... et c'est là que les choses comment à devenir compliquée.

La seule parade à ceci que je connaisse, c'est d'imposer une synchronisation / mise à jour avec une autorité centrale de façon régulière. C'est un système couramment utilisé dans les jeux vidéos en ligne, par exemple.

Là où ça commence à poser des soucis, c'est que beaucoup d'entreprises refusent catégoriquement, et je les comprends, de laisser leurs serveurs internes communiquer avec l'extérieur... Quand ils ne sont pas carrément sur un sous-réseau totalement isolé de l'extérieur ! La seule solution, c'est d'imposer, par contrat, une obligation de migration lors d'une mise à jour sous peine d'invalider la clause de maintenance / garantie. Mais c'est une épée à double tranchant : le jour où tu te loupes sur une MAJ et que tu introduis une régression, tu peux être certain que tous les clients te tombent sur la tronche en réclamant des pénalités pour le temps d'indisponibilité lié à la régression...

[Lucas Panny]

Je suis décidé après mure réflexion de ne pas m'engager dans la création d'un client-serveur car quel protocole réseau inventé encore!!!

Mon choix c'est l'application autour du web! Mon soucis c'est la sécurité, j'opte alors pour l'utilisation de https://, du SSL quoi mais je cherche encore comment le mettre en oeuvre sur Apache

[Hephaistos007]

euh... c'est étrange d'opposer application client/serveur et application Web. Une application web est par définition une application client/serveur.

[souviron34]

Comment ?

Mais on ne m'avait pas tout dit

Ben le Ouaibe, c'est pas un truc en soi ?? ça marche pas tout seul ?? Tu branches et tout le monde a ton adresse , c'est pas ça ??

Ah que de désillusions !!

[_skip]

Franchement, sans autres détails sur l'application et les interactions utilisateurs, j'ai du mal à savoir comment on peut dire client riche c'est mieux, ouaibe c'est mal.

[randriano]

Je vois que vous êtes familiers avec les applications lourdes mais avec un soucis de centraliser

Gardez la programmation en utilisant des langages comme C++, Delphi ou Java mais pour le serveur optez pour les WEBSERVICES!! Là vous n'avez pas à se soucier de créer des protocoles, etc car juste utiliser le canal HTTP

[MoncefKhalifa]

Quelque soient les technologies et les environnements à utiliser un invariant mérite de ne pas être négligé : C'est la conception. C'est une étape importante consommatrice de ressources et constitue l'investissement initial le plus stable.

Quant aux choix technologiques je pense qu'il ne faut pas oublier que : L'informatique n'est pas l'Art pour l'Art mais l'outil au service de l'entreprise. Il y a donc une connotation économique à ne pas négliger. Cet aspect doit être observer lors de l'étape de développement mais aussi et surtout tout au long de l'utilisation du système à mettre en place (sécurité, maintenance, mise à jour, migration etc...).

Pour venir aux choix, je tiens à préciser qu'il y pas une seule vérité. Ce qui me parait essentiel est :

1/ Web ou pas (client léger ou lourd) : SI les utilisateurs sont regroupés au sein d'un même réseau local (LAN), les outils permettant la conception d'applications autour d'interfaces riches et conviviales sont plus nombreux, plus mures et plus rapides. La solution Windev citée au premier message en est l'une des meilleures (Avis personnel).

2/ Pour un développement Web, Utiliser PHP, .NET ou JAVA en utilisant ou pas de Framework (Struts, Sping, Seam, PLay...). Je dirais qu'il y a vraiment où se perdre et pour toute une carrière avant de faire le choix. Aucun patron ne permettra une telle débauche. La réponse à mon avis est d'utiliser l'environnement qu'on domine le plus (connotation économique oblige).

Pour faire un choix d'avenir sur lequel on peut se former, la petite expérience à laquelle j'ai abouti et qui me semble raisonnable et sur laquelle je n'ai pas encore atteint les performance professionnelles acceptables, je retiens : JAVA, JSF, EJB et SEAM (à discuter).

3/ Pour ce qui est de l'IDE : son choix dépend de l'environnement de développement retenu. au cas où plusieurs IDE supportent l'environnement choisi, il y lieu de pencher pour l'IDE qui fourni le plus d'utilitaires.

Pour l'environnement sus-cité (JAVA, JSF, EJB et SEAM), ECLIPSE avec Jboss tools me parait le plus indiqué.
NetBeans, Jdevelopper constituent des environnement envisageables