Discussion :

[fomazou]

Bonjour,

Je cherche à savoir quel serait le meilleur choix entre les environnements WinDev et Java ?
J'ai lu des discussions et la plupart sont en faveur de Java pour des grosses applications. Cependant, il s'est passé du temps et à présent on en est à WinDev 20 il me semble.

Je travaille actuellement dans les services publiques et nous (informaticiens) sommes appelés à suivre un projet passé par DAO. Le problème est que le prestataire opte pour WinDev; pourtant l'ampleur du projet me fait croire que WinDev ne pourra pas convenir. En réalité je ne connais pas vraiment WinDev. Java, oui et surtout je peux citer les applications de la même envergure qui fonctionnent.

A propos de l'envergure il s'agit d'une application 3-tiers (traçabilité forestière) qui devra faire face à de nombreuses requêtes des clients pour le serveur et sur de longues distances avec éventuellement divers appareils tels que PDA, Tablette, Téléphone, ordinateur....

Les principaux critères attendus :

• Robustesse
• Portabilité
• Maintenance évolutive et corrective
• Rapidité
• Modularité

Merci pour votre contribution.

[tchize_]

Je comprends ton inquiétude, mais soyons honnête. Tu préfère que le prestataire prenne un langage peut être inadapté mais respecte le cahier des charge. Ou qu'il prenne un langage qu'il ne maitrise pas, fasse n'importe quoi avec et finisse avec une bouse en java

J'ai tendance à dire qu'en tant que client, ce n'est pas à toi de choisir vraiment la technologie. Si les points que tu mentionne ne sont pas dans le cahier des charges, le prestataire s'en fou, un peu de réalisme. Coté rapidité de dev, que je sache, windev c'est un peu comme un gros lego duplo. C'est facile de coder des applications data simple, c'est compliqué de faire des trucs tordus avec parce qu'il y a pas les briques qu'il faut. Mais je ne connais pas assez, pour moi windev c'est le langage de "programmation" pour ceux qui veulent apprendre à programmer par drag and drop, et qui a besoin de nanas à poil sur la couverture pour vendre.

[lankoande]

Je comprends ton inquiétude, mais soyons honnête. Tu préfère que le prestataire prenne un langage peut être inadapté mais respecte le cahier des charge. Ou qu'il prenne un langage qu'il ne maitrise pas, fasse n'importe quoi avec et finisse avec une bouse en java

J'ai tendance à dire qu'en tant que client, ce n'est pas à toi de choisir vraiment la technologie. Si les points que tu mentionne ne sont pas dans le cahier des charges, le prestataire s'en fou, un peu de réalisme...

Suis du même avis que tchize. L'environnement de développement que le prestataire va utiliser ne vous intéresse pas, pourvu que le produit final soit obtenu et que vous ayez le résultat attendu.

[Laurent.B]

Bonjour,

Suis du même avis que tchize. L'environnement de développement que le prestataire va utiliser ne vous intéresse pas, pourvu que le produit final soit obtenu et que vous ayez le résultat attendu.

Désolé mais pour moi, cela s'appelle "ne pas voir plus loin que le bout de son nez". S'il n'y a pas de transfert de compétences, c'est d'une grand absurdité, sinon ça peut aller à partir du moment où l'on sait que la maintenabilité est assurée.
Pour les autres critères faut voir.

Comme il s'agit de services publiques, raison de plus pour faire les choses correctement et de façon pérenne, sans se lier trop fortement à des prestataires ou éditeurs en particulier.

Je ne saurais critiquer WinDev par contre, je ne le connais pas mais il est vrai que je n'ai jamais eu envie de m'y pencher.

[Gugelhupf]

je ne le connais pas mais il est vrai que je n'ai jamais eu envie de m'y pencher.

Moi en tant que développeur quand je vois ça :

WinDev utilise des formats de fichier propriétaire sous forme binaire. Ce qui implique l'utilisation exclusive du gestionnaire de source maison (GDS) ainsi que le moteur de recherche de l'EDI. Le code ne peut pas être édité via un logiciel classique tel que le bloc-notes et surtout ne peut être mis sous contrôle de version dans un système standard tel que Subversion, Git ou Mercurial, par exemple. En fait, le développeur WinDev est totalement lié à l’environnement de développement vendu par l'éditeur.

Version 17 « 917 nouveautés » [...] Version 18 « 918 nouveautés » [...] Version 19 « 919 nouveautés » [...] Version 20 « 920 nouveautés »

Le WLangage permet de programmer en français, en anglais et en chinois [...] voire en mélangeant les langues

En encore l'article Wikipédia rempli d'humour :

À partir de la version 19 les champs peuvent être créés par pure programmation. Il est cependant toujours impossible (2015) de créer des classes dérivées depuis les champs proposés, ce que permet la plupart des autres langages depuis le siècle dernier.

... je me pose des questions

Sources : https://fr.wikipedia.org/wiki/WinDev , https://fr.wikipedia.org/wiki/WLangage

[Népomucène]

Windev fonctionne depuis des années déjà et continue d'être très dynamique.
Il a été conçu pour faire du développement rapide ; comme dit _Tschize, c'est du "duplo" plutôt que du "lego"
Il existe une communauté de développeurs Windev et donc, en cas de défaillance du fournisseur, il est possible d'en trouver un autre.

Fonctionnellement, c'est sûr que cela n'a pas la même portée que java
mais si cela répond aux spécifications de l'application alors pourquoi pas ?

Par contre si tu prévois une grosse base de données, alors il peut être intéressant
de demander au fournisseur de passer sur du Sql Server ou Oracle ou MySql par exemple.
Après, il est facile d'y connecter des outils de reporting indépendants de Windev ce qui limite la dépendance au fournisseur.

[Gugelhupf]

Tu préfère que le prestataire prenne un langage peut être inadapté mais respecte le cahier des charge. Ou qu'il prenne un langage qu'il ne maitrise pas, fasse n'importe quoi avec et finisse avec une bouse en java

C'est sûr qu'il ne fait pas utiliser une techno qu'on ne maitrise pas, mais WinDev n'a pas l'air d'être une techno super ouvert, le jour où tu changes de prestataire tu perdras surement en "maintenance évolutive et corrective" et autres critères cités.