Discussion :

[Bluedeep]

Je vois ce que vous voulez-dire, mais dans ce cas, on ne parle plus de la même chose. Ce n'est plus totalement un intranet, puisqu'il y a utilisation de ligne extérieure pour la gestion du réseau, et donc risque de piratage, mais c'est un autre point.

De ce point de vue, une appli client léger ou client lourd est logée à la même enseigne.

[Bluedeep]

J'ai écrit ça moi ?

Non, c'est Barsy, mais c'est toi qui a répondu sur la réponse que je lui faisait. Ergo, je suis obligé de considérer que tu reprends ces arguments. Il suffit de relirele fil, ce n'est pas très compliqué.

Ben le déploiement et la maintenance c'est vraiment l'argument choc.

Le déploiement est en effet un argument. L'aspect maintenance me semble beaucoup moins pertinent.

L'aspect multi-plateforme également.

L'aspect multiplateforme est rarement important en entreprise.
En revanche, le client léger présente un énorme avantage que personne n'évoque ici (même parmis les sectateurs du client léger), c'est la possibilité de différer/séquencer les changements de parcs de postes utilisateurs : a priori on n'a moins besoin de puissance "locale".

Ou encore incluant des mobiles de toute taille !

C'est précisément sur les mobiles que je ne choisirais jamais une appli client léger pour une solution entreprise. L'impossibilité inhérente à une appli client léger de fonctionner en mode déconnecté avec post syncrhonisation des donnéesdisqualifie a priori ce choix pour une appli d'entreprise.

Le dernier projet mobilité dont je me suis occupé consister justement à virer une appli client léger sur téléphone pour la remplacer par une client lourd,précisément pour cette raison.

Après au niveau des widgets je ne vois pas tellement de différence.

Entiérement d'accord la dessus. (sauf applications type CAO/DAO).

[Jon Shannow]

cette distinction n'a pas lieu d'être, si le poste distant est sécurisé, qu'il passe par un VPN c'est juste un Intranet étendu. Il existe des clients VPN avancés qui contrôlent la sécurité du poste avant d'activer le tunnel.

de plus, un Intranet national peut très bien être mis en place sur des lignes spécialisées (je pense que c'est le cas du CNFP), c'est juste plus cher que de passer par un VPN sur Internet.

Quelque soit le système que tu mets en place, l'utilisation des lignes adsl pour un tunnel VPN met un risque sécuritaire sur tes données. Le risque 0 est un mythe !
Ensuite, un intranet national sur des lignes spécialisées se rapproche quand même fortement d'un réseau local, non ?

[diam's]

J'ai un peu l'impression que ce topic part en sucette et dérive largement par rapport au sujet initial, non ?

Donc, je vais continuer aussi dans le hors sujet

Beaucoup de métiers IRL, comme cela à déjà été dit dans beaucoup de messages précédents, n'ont que faire de l'évolution des outils informatiques tant que ceux qu'ils utilisent leur donne satisfaction. Ce qui est important dans la phrase précédente, c'est "outils". Pour n'importe quel artisan, un PC est un outil au même titre qu'un pétrin ou qu'un chalumeau.

La puissance des PC, excusez du peu, est très rarement utilisée à 100% dans les entreprises (avoir un carte graphique tip top pour afficher du texte, c'est pas franchement obligatoire, sans parler de la puissance des CPU disproportionnée par rapport aux besoins de la majorité des TPE). Hors la puissance de PC actuellement sert à faire fonctionner le flash et compagnie. Même sur les sites de mes grossistes, il y a du flash à ch*er... alors que ce n'est absolument pas utile, et que cela ne rend pas le site plus ergonomique.

Par contre, ce qui est énervant, c'est cette "obsolescence". Un exemple assez récent :
- J'ai un ami qui travaille chez un menuisier-agenceur
- ils utilisent des machines-outils dont certaines ont plus de 50 ans (si, si), et pour lesquelles on trouve toujours des pièces. Ils ont même un vieux tour à bois qui date de juste après la première guerre mondiale (en état de marche, lui aussi)
- ils utilisent aussi des machines CN (commandes numériques), dont l'une des plus agées avait une 30aine d'année(dans les alentours de 1985). Ils en ont aussi une qui date d'avant 1970, a ce qu'il me dit).
- je dis "avait" car elle ne pouvait être mise à jour (ententez : le programme d'usinage) que via un soft qui tournait sur une vieille bécane (win 95) - Note : le soft avait été porté par le fabricant sur win95 alors qu'au départ il ne fonctionnait que sur un OS dont on ne sait rien... Il y a peu, le PC win95 à rendu l'ame... Pas grave, on va prendre un autre PC, y installé le soft et "roule ma poule"... Pas de bol : ils n'ont pas réussi à le faire fonctionner (ou de façon très imparfaite) sur aucun des OS qu'ils ont tentés (XP et 7), malgré l'intervention de plusieurs informaticiens.

Et là vous allez me dire :
- ils n'ont qu'à contacter le fabricant et obtenir la dernière version du prog ! Ben non, le fabricant a fait faillite il y a plus de 10 ans
- ils n'ont qu'à faire réécrire le programme avec les specs de la machine ! Oui, mais non. Personne n'a les specs.

Résultat : ils disposent d'une CN en parfait état de marche, qui va rester bloquée "à vie" sur le programme qu'elle a en mémoire. Pour pouvoir à nouveau produire, ils vont devoir investir plus de 50000 € dans une nouvelle CN. Et le plus drole, dans tout ça, c'est qu'en attendant la livraison de la nouvelle bécane, ils bossent en partie sur la "grand-mêre" (mais si, rappellez vous, la machine qui date de 1953 ...). C'est moins rapide, mais ça tombe pas en panne...

Tout ça pour dire que le patron de mon collègue, si vous lui parler "informatique" et "mise à jour", "évolution", "migration du parc matériel", faites le avec une tenue de footballeur américain , parce que c'est un beau bébé de 120 kg / ~2.04 m et pas franchement du genre rigolard quand il est énervé - donc site web, cloud et autres joyeuseté du virtuel, il s'en tape. Tout ce qui l'interesse, c'est de faire bosser ses 53 salariés sans perdre d'argent.

[Barsy]

C'est précisément sur les mobiles que je ne choisirais jamais une appli client léger pour une solution entreprise. L'impossibilité inhérente à une appli client léger de fonctionner en mode déconnecté avec post syncrhonisation des donnéesdisqualifie a priori ce choix pour une appli d'entreprise.

Le dernier projet mobilité dont je me suis occupé consister justement à virer une appli client léger sur téléphone pour la remplacer par une client lourd,précisément pour cette raison.

Le mobile pose un autre problème : l'incompatibilité entre les marques et les OS. J'ai eu récemment une appli mobile à faire, et elle a du être fait en client léger car dans l'entreprise du client, chaque service (voire utilisateur) avait un modèle de téléphone différent. En client lourd, il aurait fallu faire une version de l'appli par OS.

Concernant la maintenance des applications, c'est franchement bien plus simple pour détecter un problème sur un serveur que sur un poste client. Avec les clients lourd, le problème ne se produit que sur le poste de untel mais pas sur les autres à cause d'une mauvaise config du poste, ou alors il ne se produit que dans tel service et pas dans tel autre, parce qu'ils sont les seuls à avoir reçu des nouvelles machines. Résultat, il faut fouiller les machines à la recherche d'une solution (pour peu que les utilisateurs soient sur le même site et pas à l'autre bout de la France)...

Donc oui, les application client léger se maintiennent bien plus facilement.

[souviron34]

Y'a quand même quelques trucs qui me rendent perplexe....


Je lis ci-dessus depuis quelques pages que le Web est avantageux pour sa facilité de déploiement, son aspect multi-plateforme, ses possibilités de développement d'applis multi-fenêtres, etc etc, et aussi dans la partie avant que il faut suivre les normes...

Jusque-là ça va...


Sauf que des normes, il en existe, depuis TRES longtemps, stables, multi-plateformes, avec déploiement et multi-fenêtrages et multi-stations et multi-session et multi-écrans et client-serveur et tout et tout : depuis 1984 existe XWindow (petit nom X11),, avec une norme , et qui remplit TOUTES ces fonctionalités...

Alors je veux bien les arguments donnés plus haut, mais ce sont des arguments faux, basés sur l'omni-présence de M$ et le soutien (implicite) de la grande majorité des supporters du Web ici présents..

Tous ces "langages", "outils", tels que ceux cités plus haut ne font que réinventer la roue (tiens, c'est pas un des arguments qu'on m'a envoyé plus haut ???) en amenant des incompatibilités grandissantes et évoluant plus vites que la musique, alors que des standards FIXES, ou très peu évolutifs PARCE QUE BIEN CONCUS, existent....


ça me fait doucement rigoler (jaune)....



PS: tellement bien conçu au départ que ça a quand même donné Mosaic... Et changer l'interpréteur de HTML était simple sans rien changer d'autre....

[Jon Shannow]

J'ai un peu l'impression que ce topic part en sucette et dérive largement par rapport au sujet initial, non ?

Donc, je vais continuer aussi dans le hors sujet

Beaucoup de métiers IRL, comme cela à déjà été dit dans beaucoup de messages précédents, n'ont que faire de l'évolution des outils informatiques tant que ceux qu'ils utilisent leur donne satisfaction. Ce qui est important dans la phrase précédente, c'est "outils". Pour n'importe quel artisan, un PC est un outil au même titre qu'un pétrin ou qu'un chalumeau.

La puissance des PC, excusez du peu, est très rarement utilisée à 100% dans les entreprises (avoir un carte graphique tip top pour afficher du texte, c'est pas franchement obligatoire, sans parler de la puissance des CPU disproportionnée par rapport aux besoins de la majorité des TPE). Hors la puissance de PC actuellement sert à faire fonctionner le flash et compagnie. Même sur les sites de mes grossistes, il y a du flash à ch*er... alors que ce n'est absolument pas utile, et que cela ne rend pas le site plus ergonomique.

Par contre, ce qui est énervant, c'est cette "obsolescence". Un exemple assez récent :
- J'ai un ami qui travaille chez un menuisier-agenceur
- ils utilisent des machines-outils dont certaines ont plus de 50 ans (si, si), et pour lesquelles on trouve toujours des pièces. Ils ont même un vieux tour à bois qui date de juste après la première guerre mondiale (en état de marche, lui aussi)
- ils utilisent aussi des machines CN (commandes numériques), dont l'une des plus agées avait une 30aine d'année(dans les alentours de 1985). Ils en ont aussi une qui date d'avant 1970, a ce qu'il me dit).
- je dis "avait" car elle ne pouvait être mise à jour (ententez : le programme d'usinage) que via un soft qui tournait sur une vieille bécane (win 95) - Note : le soft avait été porté par le fabricant sur win95 alors qu'au départ il ne fonctionnait que sur un OS dont on ne sait rien... Il y a peu, le PC win95 à rendu l'ame... Pas grave, on va prendre un autre PC, y installé le soft et "roule ma poule"... Pas de bol : ils n'ont pas réussi à le faire fonctionner (ou de façon très imparfaite) sur aucun des OS qu'ils ont tentés (XP et 7), malgré l'intervention de plusieurs informaticiens.

Et là vous allez me dire :
- ils n'ont qu'à contacter le fabricant et obtenir la dernière version du prog ! Ben non, le fabricant a fait faillite il y a plus de 10 ans
- ils n'ont qu'à faire réécrire le programme avec les specs de la machine ! Oui, mais non. Personne n'a les specs.

Résultat : ils disposent d'une CN en parfait état de marche, qui va rester bloquée "à vie" sur le programme qu'elle a en mémoire. Pour pouvoir à nouveau produire, ils vont devoir investir plus de 50000 € dans une nouvelle CN. Et le plus drole, dans tout ça, c'est qu'en attendant la livraison de la nouvelle bécane, ils bossent en partie sur la "grand-mêre" (mais si, rappellez vous, la machine qui date de 1953 ...). C'est moins rapide, mais ça tombe pas en panne...

Tout ça pour dire que le patron de mon collègue, si vous lui parler "informatique" et "mise à jour", "évolution", "migration du parc matériel", faites le avec une tenue de footballeur américain , parce que c'est un beau bébé de 120 kg / ~2.04 m et pas franchement du genre rigolard quand il est énervé - donc site web, cloud et autres joyeuseté du virtuel, il s'en tape. Tout ce qui l'interesse, c'est de faire bosser ses 53 salariés sans perdre d'argent.

Je te rejoins sur ce point, toutefois, n'est-il pas possible de récupérer un PC un peu ancien, et de lui installer W95 afin de faire fonctionner le soft ?

Pour le reste, tu as raison. Mon père avait un scanner A3 qui fonctionnait sous W95, en se connectant sur une carte SCSI "customizer" par le fabricant. Hélas, le fabricant est OUT, et pas de pilote pour XP ! Le scanner qui fonctionnait très bien, est mort, sauf à rester sous W95 ! Oui, mais, le logiciel de CAO qu'il utilise nécessite XP minimum pour fonctionner !

[Paul TOTH]

@diam's

la règle a calculer aussi fonctionne toujours de nos jours...

c'est pas bien compliqué de monter un W95 sur une vieille bécane, voir sur un PC récent en VirtualBox, il devrait surtout changer d'informaticiens

et s'il utilise une machine à CN au lieu d'un bon vieux tour manuel, c'est qu'il y gagne, la machine doit être amortie depuis bien longtemps et il veux juste pas réinvestir, ben dans ce cas il achète pas son PC chez Auchan mais chez un broqueur.

[Bluedeep]

Le mobile pose un autre problème : l'incompatibilité entre les marques et les OS. J'ai eu récemment une appli mobile à faire, et elle a du être fait en client léger car dans l'entreprise du client, chaque service (voire utilisateur) avait un modèle de téléphone différent. En client lourd, il aurait fallu faire une version de l'appli par OS.

Ca faisait parti de la stratégie projet et de la stratégie de déploiement : choix unifié du mobile et déploiement sequencé en fonction du remplacement du parc. Planifié sur 18 mois. Encore une fois, une appli mobile "pro" de gestion qui ne supporte pas le mode déconnecté ne me semble pas un choix possible ni viable.

Concernant la maintenance des applications, c'est franchement bien plus simple pour détecter un problème sur un serveur que sur un poste client. Avec les clients lourd, le problème ne se produit que sur le poste de untel mais pas sur les autres à cause d'une mauvaise config du poste,

La tu mélanges un problème amont (mauvais suivi et non unification des configs, pas de déploiement des KBs et SPs,etc ... ) avec un problème de maintenabilité.

Effectivement en inventant des problèmes qui n'ont pas lieu d'exister sauf mauvaise organisation de la DSI, on peut créer des arguments ex-nihilo.

Donc oui, les application client léger se maintiennent bien plus facilement.

Je maintiens que je ne suis pas du tout d'accord la dessus.

[Bluedeep]

Résultat : ils disposent d'une CN en parfait état de marche, qui va rester bloquée "à vie" sur le programme qu'elle a en mémoire. Pour pouvoir à nouveau produire, ils vont devoir investir plus de 50000 € dans une nouvelle CN.

Là, peut être qu'un peu de travail de reverse ingeneering sur la version 95 (un OS 95 faut pas exagérer ça se trouve) aurait permis de trouver une solution sans doute moins couteuse. (un peu moins).

[Marco46]

Le déploiement est en effet un argument. L'aspect maintenance me semble beaucoup moins pertinent.

Ben tu disposes d'une telle flexibilité pour effectuer la maintenance que ça affecte positivement ta manière de travailler et l'expérience utilisateur. A des années-lumières du bordel que c'est pour maj un parc logiciel client lourd.

Donc on peut dire que la maintenance est plus facile, pas en terme de difficulté de développement, mais en terme de mise en pratique générale.

Au cours du développement ça permet également d'effectuer plus facilement des incréments rapides dans la release de fonctionnalités à l'utilisateur.

L'aspect multiplateforme est rarement important en entreprise.
En revanche, le client léger présente un énorme avantage que personne n'évoque ici (même parmis les sectateurs du client léger), c'est la possibilité de différer/séquencer les changements de parcs de postes utilisateurs : a priori on n'a moins besoin de puissance "locale".

Qu'entends-tu par différer/séquencer les changements de parcs de postes ?

Ceci dit l'aspect multi-plateforme peut être important, ça dépend du contexte.

C'est précisément sur les mobiles que je ne choisirais jamais une appli client léger pour une solution entreprise. L'impossibilité inhérente à une appli client léger de fonctionner en mode déconnecté avec post syncrhonisation des donnéesdisqualifie a priori ce choix pour une appli d'entreprise.

La pareil ça dépends du contexte, j'ai eu le même cas que Barsy (parc très hétérogène), ça sauve la vie.
Mais le coup du mode déconnecté est un vrai problème et un vrai argument.

[Jon Shannow]

En fait vous argumentez sur un point positif coté développeur en oubliant le coté utilisateur qui, lui se retrouve avec un logiciel lent pas pratique et peu convivial.

[Barsy]

La tu mélanges un problème amont (mauvais suivi et non unification des configs, pas de déploiement des KBs et SPs,etc ... ) avec un problème de maintenabilité.

Effectivement en inventant des problèmes qui n'ont pas lieu d'exister sauf mauvaise organisation de la DSI, on peut créer des arguments ex-nihilo.

Je ne vois pas en quoi "j'inventerai des problèmes qui n'ont pas lieu d'exister"...

Les problèmes se posent et il faut les résoudre, point. Et dans les grosses sociétés, les parcs informatiques sont loin d'être uniformes, et le problème ne vient pas d'une "mauvaise organisation de la DSI", c'est juste impossible de renouveler d'un coup un parc composé de plusieurs milliers de machines et de le rendre homogène.

Alors oui, ça arrive que untel ait son poste en Français et qu'un autre l'ait en Anglais (simplement parce que justement, il est anglais), ça arrive que untel ait Office 2003 et un autre Office 2010, ça arrive que untel ait un logiciel installé sur son poste dont un autre n'a pas besoin (tous les employés d'une boîte n'occupent pas la même fonction). Il y a des tonnes de raisons à ce qu'il y ait des postes configurés différemment au sein d'une même entreprise.

Et de même, quand une entreprise à 50 services avec 50 directeurs qui choisit la marque du mobile pour ses employés (ou qui leur laisse le choix), avec le même problème qu'un parc de téléphone mobile ne peut pas non plus se remplacer d'un seul coup, il est bien difficile dans ce cas de choisir la solution "client lourd" pour une application mobile.

[Bluedeep]

Ben tu disposes d'une telle flexibilité pour effectuer la maintenance que ça affecte positivement ta manière de travailler et l'expérience utilisateur.

Je ne vois vraiment pas le rapport entre la flexibilité de déploiement et les tâches de maintenance/évolution.
Si il s'agit d'une maintenance évolutive importante, elle sera de toute manière testé sur un panel utilisateur avant de passer en version release.

A des années-lumières du bordel que c'est pour maj un parc logiciel client lourd.

Quel bordel de maj ? les maj client lourd se font de toute manière en batch de nuit

Donc on peut dire que la maintenance est plus facile, pas en terme de difficulté de développement, mais en terme de mise en pratique générale.

Raccourci que pas grand chose ne soutient.

Au cours du développement ça permet également d'effectuer plus facilement des incréments rapides dans la release de fonctionnalités à l'utilisateur.

Les phases de recettes étant par définition identiques je ne vois pas du tout en quoi cela permet des"incréments rapides".

Qu'entends-tu par différer/séquencer les changements de parcs de postes ?

A priori une appli client léger a plus de chance de pouvoir fonctionner sur PC qui a 5 ans qu'une appli client lourd pour laquelle on a fait des choix qui peuvent imposer le dernier release d'OS ou de framework par exemple. Donc le changement de parc est moins critique.

Ceci dit l'aspect multi-plateforme peut être important, ça dépend du contexte.

Absolument, mais aucune des entreprisses dans lesquelles je suis intervenue (du moins disons les 15 dernières années) n'utilisait en général de plateforme client hétérogènes sauf sur des panel d'utilisateurs spécifiques (CAO/DAO) qui justement sont en général peu concernés par les applis gestions. Mais l'argument a son poids.

[Bluedeep]

Je ne vois pas en quoi "j'inventerai des problèmes qui n'ont pas lieu d'exister"...

Les problèmes se posent et il faut les résoudre, point. Et dans les grosses sociétés, les parcs informatiques sont loin d'être uniformes, et le problème ne vient pas d'une "mauvaise organisation de la DSI", c'est juste impossible de renouveler d'un coup un parc composé de plusieurs milliers de machines et de le rendre homogène.

Tout dépend de ce que tu entend par hétérogénéité du parc. Bien sur dans toutes les boites tu vas trouver des PC en 7 et d'autres encore en XP/SP3. En revanche, on trouve rarement du PC+Linux+McIntosh, ou du moins quand c'est le cas, rare seront les applicatifs qui seront utilisées par les utilisateurs toutes ces plateformes (sauf appli transverse type "gestion de consommé" pour les quel ont choisi en général justement le client léger).

Alors oui, ça arrive que untel ait son poste en Français et qu'un autre l'ait en Anglais (simplement parce que justement, il est anglais),

Si ça , ça un impact sur l'appli c'est clairement un problème de conception/réalisation et rien d'autre.

ça arrive que untel ait Office 2003 et un autre Office 2010, ça arrive que untel ait un logiciel installé sur son poste dont un autre n'a pas besoin (tous les employés d'une boîte n'occupent pas la même fonction). Il y a des tonnes de raisons à ce qu'il y ait des postes configurés différemment au sein d'une même entreprise.

Oui, mais ces configs sont connues donc la contraintes est prise en compte en phase de conception.

, il est bien difficile dans ce cas de choisir la solution "client lourd" pour une application mobile.

On peut dire à l'inverse qu'il est presque impossible de choisir la solution client léger suuivant la criticité de l'usage de l'application.

[diam's]

la règle a calculer aussi fonctionne toujours de nos jours...

oui, mais y'a franchement moins de mécanique et de sollicitation sur la règle - ce que je disais, c'est qu'il existe toujours des pièces pour cette bécane...

c'est pas bien compliqué de monter un W95 sur une vieille bécane, voir sur un PC récent en VirtualBox, il devrait surtout changer d'informaticiens

Encore faut-il disposer d'une version et d'une licence W95... Mais c'est vrai qu'en frolant la ligne, il doit y avoir moyen de trouver un 95 par là, je suis d'accord

et s'il utilise une machine à CN au lieu d'un bon vieux tour manuel, c'est qu'il y gagne, la machine doit être amortie depuis bien longtemps et il veux juste pas réinvestir,

Amortie ? oui, et alors. Le boulanger ne jette pas son four dès qu'il est amorti, parce que c'est à partir de ce moment qu'il dégage une marge suffisamment intéressante pour mettre de l'argent de coté et pourvoir réinvestir plus tard (et pas forcément pour remplacer une machine amortie mais qui lui donne pleinement satisfaction)... Tu ne jettes pas tes outils de développement une fois qu'ils sont amorti, si ? Ni l'assiette dans laquelle tu manges (je considère qu'une assiette utilisée plus de 10 fois est amortie...). Si il utilise une CN, c'est certes pour le temps mais surtout, je pense, parce que cet outil permet de faire en une passe/opération ce qui mobilise normalement 7 ou 8 machines outils normales (fraiseuses, défonceuses, dégauchisseuse, etc...), avec la manutention et les risques de "casse" de la pièce usinée qui vont avec (ils travaillent aussi bien du bois précieux que des planches en mélaminé avec des coloris "à la c*n" (qui dit méla, dit rayures possibles ou angles fragiles à chaque manutention).

ben dans ce cas il achète pas son PC chez Auchan mais chez un broqueur.

A mon avis, et d'après ce que j'en sais, il se fourni chez un revendeur local, et pour une machine outils, je suis pas sur qu'ils aient ça chez carouf et cie

Là, peut être qu'un peu de travail de reverse ingeneering sur la version 95 (un OS 95 faut pas exagérer ça se trouve) aurait permis de trouver une solution sans doute moins couteuse. (un peu moins).

Euh, et le temps... parce que le reverse, pourquoi pas (je pense pas qu'ils y ai pensé), mais combien de temps pour arriver à une solution utilisable en production... Là, faut que ça sorte, il y a quelques magasins qui attendent leur mobilier - la machine outil est livrée sous 15 jours (vive l'Allemagne - elle doit être en cours d'install à l'heure ou j'écris, si elle n'est pas déjà en prod). Si tu as déjà travaillé pour des "chaines" d'enseigne, tu devrais savoir qu'un retard se paye (et cher : soit des pénalités, soit plus de contrat... ) - Dans l'industrie, l'argent n'est pas forcement ce qui manque, par contre, on ne peut pas dire la même chose pour le temps. Autre point : pendant que quelqu'un se penche sur la version W95, les personnes que la CN fait travailler (ouvriers, monteurs, ...), ils font quoi ? Ils balaient l'atelier, ils pointent au chomage technique, ils restent "à la soupe" ?

[Paul TOTH]

Autre point : pendant que quelqu'un se penche sur la version W95, les personnes que la CN fait travailler (ouvriers, monteurs, ...), ils font quoi ? Ils balaient l'atelier, ils pointent au chomage technique, ils restent "à la soupe" ?

tu as combien de personnes sur une machine à CN ? le but de ces machines c'est tout de même de faire le travail tout seul, il y a tout une étape de "programmation" mais pour le reste...ceci dit toutes les journées passées sans la machine c'est de la perte brute en effet.

quand à la licence 95 il devait déjà en avoir une. d'ailleurs c'est quoi qui a rendu l'âme sur ce PC ? le disque dur qui possède évidemment des sauvegardes ou l'alim ? la carte mère ? je pense franchement qu'il devrait changer d'informaticien

[Marco46]

Je ne vois vraiment pas le rapport entre la flexibilité de déploiement et les tâches de maintenance/évolution.
Si il s'agit d'une maintenance évolutive importante, elle sera de toute manière testé sur un panel utilisateur avant de passer en version release.

T'as même pas besoin d'avertir l'utilisateur. Tu bloques juste le site avec une page spéciale, t'attends que chaque utilisateur en cours ait fini sa session ou bien encore tu kick tout le monde.
Puis tu fais ta maj rapido puis tu rallumes et le tour est joué.

Je parlais justement pas d'une maj importante, je parlais de par exemple découvrir une coquille et vouloir la corriger vite fait. C'est ce que j'appelle la flexibilité est c'est très appréciable.

Quel bordel de maj ? les maj client lourd se font de toute manière en batch de nuit

Ça ça dépend de tes méthodes. Mais même ça ça veut dire qu'il faut laisser les postes clients allumés (donc prévenir chaque user ce qui est le bordel), et même si tu as un déploiement par programmation il faudra bien à un moment ou à un autre que ton utilisateur clique sur quelque chose ne serait-ce que pour l'informer que la mise à jour s'est bien déroulée. Et là t'as toujours une bonne partie des users qui vont t'inonder d'appels pour savoir si c'est normal et poser 10K de questions.

Bref, c'est la merde. Enfin je trouve.

Les phases de recettes étant par définition identiques je ne vois pas du tout en quoi cela permet des"incréments rapides".

Ben méthodes agiles quoi ... Ton user veut telle fonctionnalité -> hop tu la lui rajoutes, pas besoin de planifier 15 jours à l'avance une mise en test.

A priori une appli client léger a plus de chance de pouvoir fonctionner sur PC qui a 5 ans qu'une appli client lourd pour laquelle on a fait des choix qui peuvent imposer le dernier release d'OS ou de framework par exemple. Donc le changement de parc est moins critique.

Ok.

Absolument, mais aucune des entreprisses dans lesquelles je suis intervenue (du moins disons les 15 dernières années) n'utilisait en général de plateforme client hétérogènes sauf sur des panel d'utilisateurs spécifiques (CAO/DAO) qui justement sont en général peu concernés par les applis gestions. Mais l'argument a son poids.

Là où je suis encore pour quelques jours il y a du XP, du Vista et du Seven qui cohabitent et différentes version de Win Server. Pour moi c'est un parc hétérogène.

[souviron34]

T'as même pas besoin d'avertir l'utilisateur. Tu bloques juste le site avec une page spéciale, t'attends que chaque utilisateur en cours ait fini sa session ou bien encore tu kick tout le monde.
Puis tu fais ta maj rapido puis tu rallumes et le tour est joué.

Super pour les mecs en conversation avec un client, ou pour ceux en train de modifier la BD

Et après on s'étonne que les utilisateurs n'arrêtent pas de râler contre les services infos...

Ça ça dépend de tes méthodes. Mais même ça ça veut dire qu'il faut laisser les postes clients allumés (donc prévenir chaque user ce qui est le bordel), et même si tu as un déploiement par programmation il faudra bien à un moment ou à un autre que ton utilisateur clique sur quelque chose ne serait-ce que pour l'informer que la mise à jour s'est bien déroulée.

Kesako ???

ça c'est au sys admin de le faire, pas à l'utilisateur....


L'utilisateur il s'en contre-tape que le logiciel (même maison) soit passé de 3.2.5.6.8.9 à 3.2.5.6.9.0...

Si c'est fait de nuit c'est justement pour qu'il ne voit rien..

Ben méthodes agiles quoi ... Ton user veut telle fonctionnalité -> hop tu la lui rajoutes, pas besoin de planifier 15 jours à l'avance une mise en test.

Et ceci n'a rien à voir avec dev Web ou dev non-Web, léger ou lourd, langage X ou langage Y, etc etc...

Là où je suis encore pour quelques jours il y a du XP, du Vista et du Seven qui cohabitent et différentes version de Win Server. Pour moi c'est un parc hétérogène.

euh...

Non c'est un parc de PC avec différentes versions de l'OS M$..

Sinon tu peux avoir des IBM Blade server, des HP, des Mac, des Silicon, des PC, des PCS avec Linux, des grossses machines avec MVS, avec Unix, etc etc..

ça c'est hétérogène...

[Bluedeep]

T'as même pas besoin d'avertir l'utilisateur. Tu bloques juste le site avec une page spéciale, t'attends que chaque utilisateur en cours ait fini sa session ou bien encore tu kick tout le monde.
Puis tu fais ta maj rapido puis tu rallumes et le tour est joué.

Sauf que de toutes manières cela ne relève pas des équipes études.

Je parlais justement pas d'une maj importante, je parlais de par exemple découvrir une coquille et vouloir la corriger vite fait. C'est ce que j'appelle la flexibilité est c'est très appréciable.

Idem.

Ça ça dépend de tes méthodes. Mais même ça ça veut dire qu'il faut laisser les postes clients allumés

Non, la mise à jour se fera (avec des outils comme LANDesk) à l'allumage.

(donc prévenir chaque user ce qui est le bordel),

Non.

et même si tu as un déploiement par programmation il faudra bien à un moment ou à un autre que ton utilisateur clique sur quelque chose ne serait-ce que pour l'informer que la mise à jour s'est bien déroulée.

Non, encore une fois. Cela dépend des outils de déploiement.

Et là t'as toujours une bonne partie des users qui vont t'inonder d'appels pour savoir si c'est normal et poser 10K de questions.

Curieux. En général en dehors des "pilotes" les utilisateurs ne sont pas en contacts avec les études.

Ben méthodes agiles quoi ... Ton user veut telle fonctionnalité -> hop tu la lui rajoutes, pas besoin de planifier 15 jours à l'avance une mise en test.

Là tu prends le cas particulier des méthodes Agiles, qui ont, certes, leurs avantages mais qui ne sont pas adaptées à tous les projets et ne sauraient constituer une règle générale.