Bonjour,
Nous sommes une SSII qui développe un logiciel de gestion actuellement développé en VB6.
Le client/serveur n'est plus à la "mode" il faut être maintenant full-web.
C'est une tendance qui s'affirme de plus en plus dans les demandes de nos prospects (principale raison invoquée : l'installation sur chaque poste. pourtant une solution comme TSE fonctionne très bien mais on ne peut pas grand chose contre la mode !).
Je souhaiterais avoir le témoignage des personnes qui ont eu le même problème : redévelopper leur application de gestion en full-web (des applications "lourdes" en développement, la notre représente quand même environ 10 années homme de développement donc il ne faut pas se planter sur le choix du langage).
Pour l'instant notre choix se focalise sur Java ou DotNet.
Merci d'avance pour vos avis
Et pourquoi cela ?
Encore la mode ?
D'autant plus quand on s'est déjà planté une fois en choisissant VB 6 n'est ce pas ? ;)
Votre remarque est pertinente !
Maintenant vous comprendrez que pour une petite société comme la notre (12 personnes) lorsqu'on investi 10 années homme de développement il faut minimiser les risques de "plantage" car c'est la société qui peu couler ! Donc on ne peut pas se permettre d'investir sur un langage plus ou moins répandu (même si il est très performant) car il y a le risque de sa pérennité.
La votre remarque n'est pas du tout justifiée, le choix de VB6 a été à l'époque judicieux (je suis d'autant plus libre de le dire que ce n'est pas moi qui l'ait fait !) surtout pour le développement d'un logiciel de gestion. Les informaticiens sont globalement très satisfaits de VB6. Seulement, en informatique (comme dans tous les secteurs) pour faire du business il faut toujours innover (quitte à faire du neuf avec du vieux). Même si l'ergonomie du web n'est pas vraiment adaptée aux logiciels de gestion (car il n'a pas été pensé non plus pour ça à l'origine) c'est la mode !
Vos remarques me laissent penser que vous avez certainement d'excellents préconisations pour ne pas se planter ! Dans ce cas, pouvez-vous en faire profiter tout le monde.
merci
Merci :)
Tout à fait. Et justement quand je dis "D'autant plus quand on s'est déjà planté une fois en choisissant VB 6 n'est ce pas ?" c'est que je pense que vous allez devoir ré-écrire des montages de code ce qui va coûter une fortune, alors que si vous aviez choisi un autre langage vous n'en seriez peut être pas là, ni non plus prisonnier de Windows par la même occasion.
Tout à fait d'accord avec ça! Mais alors d'accord à 110%
Et justement VB 6 n'étant ni performant ni pérenne et plutôt moins répandu que plus (même si il a eu son heure de succès) n'était pas, de mon point de vue, un bon choix.
J'ai au moins une excellente préconisation :) Utiliser un outil garanti par un standard. Je prends un exemple. Exemple non limitatif, j'insiste là dessus. Si le coeur de votre application était écrit en C vous pourriez sans doute le porter très facilement sur une autre plate-forme comme Linux si besoin.
C est un langage standard et de ce fait pérenne. Si votre logiciel avait écrit en C sans doute pour l'adapter à "la mode actuelle" auriez vous eu à envisager d'écrire du code supplémentaire, mais l'important est que probablement 90% de l'existant pouvait être repris. Repris aujourd'hui et encore repris dans 10 ans pour s'adapter à une autre mode.
J'ai dis C comme ça pour l'exemple. Mais ce qui faut retenir c'est *standard*
De ce point de vue, Java et .Net sont très à la mode en ce moment c'est incontestable. Mais ils ne sont pas standards, .Net encore moins que Java si l'on peut dire.
Ce que je peux ajouter aussi, c'est que les temps de développement en Java soit souvent prohibitifs. J'ai moins d'expérience en .Net. On "dirait' que développer en .Net est plus rapide, mais j'aime bien ce que dis angelo dans sa réponse à votre post sur le thread Java. Ca me paraît pertinent.
Quant à moi si je suis libre dans le choix, je ne choisi ni Java ni .Net parce que je ne les aime pas et leur reproche plein de choses, mais surtout, parce qu'ils ne correspondent à aucun standard industriel. Les choisir c'est être sous la dictature des fluctuations de la mode ou des facéties de Sun ou Microsoft.
Il est vrai que les standards aussi évoluent parfois eux mêmes, mais remettre une appli C au standard, (toujours pour prendre cet exemple non limitatif) n'est rien en comparaison d'une ré-écriture complète de VB6 vers Java.
Bonjour,
Je confirme un point du précédent mail, qui pourrait apparaître comme un détail, mais qui est pourtant fondamental en développement : parmi les langages conventionnels, .NET est certainement le plus productif. Nous l'utilisons dans ma société depuis les tous débuts en 2002 si je me rappelle bien, et dès la version 1.1, nous avons eu des temps de développements très réduits. Une partie vient de la mise en place de l'usine logicielle, mais une bonne partie du langage lui-même, et surtout de la librairie .NET, extrêmement fournie et homogène.
Au passage, nous étions nous aussi avec une application VB6 auparavant, et avons switché en .NET, non pour être à la mode mais pour être plus productifs et nous débarasser des problèmes inhérents à VB. Nos clients aussi voulaient du full web sans bien maîtriser les raisons de ce choix. Après discussion, il s'est avéré que c'est surtout le déploiement automatique qui les intéressait. Et ça marche également très bien avec TSE, ou ClickOnce en .NET, ou JavaStart en Java, etc.
Si je n'ai qu'un conseil à vous donner, c'est de ne surtout pas laisser vos clients vous imposer une technologie. Vous êtes un SSII : le spécialiste de l'informatique, ce n'est pas lui, mais vous. En tant que fournisseur, vous avez envers lui un devoir de conseil, et la première étape, le choix du langage, est la vôtre.
JP
Bonjour,
Je rejoins l'observation faite par jp.gouigoux.
.NET est composé d'un ensemble de langages, frameworks et outils plus ou moins intégrés qui permettent de gagner en productivité.
Le choix de VB6 est effectivement justifiable en son temps car il avait l'avantage de mixer un IDE RAD et un langage de développement, d'où son gain de productivité basé sur la facilité à développer des applications Windows.
Comme souligné dans le post précédent, l'évolution doit être argumentée par l'inventaire des facteurs résultants et opportuns.
Pour VB6, les facteurs de migration observés sont:
- Raréfaction de la compétence
- Plus de support de l'IDE par Microsoft depuis mars 2008
- Les processus de développement ne "collent" plus aux standards actuels
- Besoin d'évoluer plus rapidement en fonction des technologies (SOA, RIA, etc...)
- Productivité des développements, time-to-market réduit et qualité améliorée
Ces facteurs doivent permettre de justifier aux décideurs le besoin de migrer vers .NET ou Java. Pour ma part, j'ai déjà fait mon choix ;-).
Ensuite, vous devez définir une architecture logicielle cible. Et là, vous avez le choix entre du full web, du RIA, du Desktop ou RDA, etc...
Encore une fois le post précédent est judicieux et prudent dans le sens où l'on remarque qu'il ne faut pas forcément succomber aux appels de la "mode" qui par définition est très volatile (sinon ce ne serait plus une mode mais un changement profond, chose sur laquelle, tant que les grands acteurs de l'informatique actuels n'ont pas clarifiés leurs visions, il ne serait pas prudent de miser). Des règles cependant: ne faites pas un choix qui va à l'encontre de la valeur ajoutée de votre logiciel (la concurrence ne vous laissera pas le temps de vous retourner pour corriger le tir), ni un choix qui vous empêchera d'évoluer vers de futures technologies. Ne soyez pas prisonnier de la "mode" pour ne pas être ensuite affublé du terme "passé de mode".
Pour ma part, quelques uns de mes clients qui ont des applications vieillissantes et qui ne peuvent investir massivement dans les nouvelles technologies (non souvent par manque d'investissement, mais plutôt par manque de compétences disponibles sur le marché), font le choix de rester en client/serveur avec un déploiement TS ou CITRIX. Sur ce point, sans vouloir faire de pub, j'orienterai aujourd'hui mon choix vers la solution Windows Server 2008 TS Web Acces et Remote Apps (nouveauté) qui permet un déploiement en 3-Tiers physiques avec contrôle d'accès sur l'application distante, comme l'aiment les DSIs et les RSIs.
Après, ce n'est que reculer pour mieux sauter. Votre projet de migration doit être plannifié le plus rapidement possible (que ce soit .NET ou Java) et les formations de vos développeurs aussi (que ce soit .NET ou Java, c'est le même combat: COO/POO - Conception/Programmation Orientée Objet). C'est certainement le saut quantique le plus difficile à réaliser et à ne pas sous-estimer lorsque l'historique est construit sur VB6.
Techniquement, si vous restez sur la même architecture que le produit actuel en VB6, il existe beaucoup de solutions techniques pour faire interopérer les développements VB6 et .NET (COM Interop par exemple ou autres mécanismes d'interopérabilité).
Pour plus d'informations, vous pouvez lire mon ancien blog sur le concept de "Migration Factory": http://blogs.msdn.com/fredeq/pages/article-the-migration-factory.aspx.
Frédéric Queudret