Discussion :

[Bluedeep]

. Alors la connerie est plus présente au monde que l'intelligence
Bon mais qu'est ce que la connerie ? sinon de l'intelligence négative

Tss... tss... Tout cela n'est pas politiquement correct.

De nos jours, de même qu'il n'y a plus de sourds ni d'aveugles juste des mal-entendants et des non-voyants, il n'y a pas non plus d''idiots, juste des mal comprenants.

[ALT]

Au risque de me répéter, quand on dit que l'utilisateur est un idiot, ça n'a rien à voir avec son QI mais avec la fait que si l'application n'est pas blindée, il y aura toujours un tachon d'utilisateur pour entrer une donnée invalide (du texte à la place d'un nombre, par exemple). Par inattention, fatigue, négligence ou... jeu.
Dire ça n'a rien de péjoratif, c'est juste un constat.

Quand on développe, on doit faire comme si l'utilisateur était idiot & qu'il ne savait pas faire la différence entre un chiffre & une lettre.
C'est un des moyens nécessaires pour réaliser du code robuste.

De la même façon qu'un constructeur automobile met des butées mécaniques pour que le conducteur ne puisse pas forcer par mégarde une commande mécanique & la rendre inutilisable : combinaison inappropriée de pignons de la boîte de vitesses, par exemple. Car il serait impensable de dire au client : "Vous avez droit à six positions du levier de vitesses, mais toutes les autres sont fautives & vous devez les éviter sous peine de blocages dangereux". C'est simplement une règle de bon sens & de bonne pratique professionnelle d'empêcher les manœuvres dangereuses.
Les programmeurs ne font pas exception.

Donc, ceux qui prennent ce conseil ("Il faut considérer que les utilisateurs sont des idiots") au premier degré font tout simplement un faux-sens. Et à lire les messages de ce fil, ils sont nombreux !

[souviron34]

Tss... tss... Tout cela n'est pas politiquement correct.

De nos jours, de même qu'il n'y a plus de sourds ni d'aveugles juste des mal-entendants et des non-voyants, il n'y a pas non plus d''idiots, juste des mal comprenants.

Tssss. Tsss.... Tu es toujours dans la mal-pensance .. ou tu retardes

Ce n'est pas non-voyants, c'est mal-voyants..

Même les non-voyants n'existent plus...

Faudra que je retrouve, j'avais un très bon document des profs sur les expressions politiquement correctes pour désigner les élèves (on ne dit pus un cancre ou un dissipé, par exemple, mais "un élève souffrant de difficultés d'apprentissage" ou "un élève souffrant de troubles de l'attention" )

Donc, ceux qui prennent ce conseil ("Il faut considérer que les utilisateurs sont des idiots") au premier degré font tout simplement un faux-sens. Et à lire les messages de ce fil, ils sont nombreux !

Personne n'a pris ceci pour un "conseil au premier degré"..

Certains ici le pensent, tout simplement .. (ou tout au moins l'ont exprimé dans les pages précédentes)

[GPPro]

Tss... tss... Tout cela n'est pas politiquement correct.

De nos jours, de même qu'il n'y a plus de sourds ni d'aveugles juste des mal-entendants et des non-voyants, il n'y a pas non plus d''idiots, juste des mal comprenants.

[HS]

Je ne suis pas complétement d'accord là, le distingo mal-voyants aveugle n'est pas du politiquement correct mais une généralisation pour prendre en compte une population qui n'est pas aveugle mais a de sérieuse difficultés de visions.

"black" vs noir ça c'est du politiquement correct. Pareil, si je dis à Souviron que c'est un vieux, ce n'est pas politiquement correct. Il est juste très expérimenté.

Edit : ça me fait penser à une réflexion de mon directeur de thèse il y a quelques années, à une époque où le campus de Grenoble était envahi par les gitans : on ne dit pas gitans mais "gens du voyage"...

[/HS]

[rimram31]

+1
Il y a également les cellules "Suivis d'exploitation" et "Incident" dans le même genre

+1 aussi...

Le plus surprenant c'est que c'est bien souvent en discutant avec le client en employant des "mots simples", les siens, que les solutions les plus simples sont trouvées Il est une matière qui devrait être enseignée absolument dans les cursus informatique, c'est la communication. Malheureusement j'ai une théorie la dessus largement vérifiée par l'expérience, les profils attirés par l'informatique ne sont pas, par nature, des communicants!

[el_slapper]

(.../...)Edit : ça me fait penser à une réflexion de mon directeur de thèse il y a quelques années, à une époque où le campus de Grenoble était envahi par les gitans : on ne dit pas gitans mais "gens du voyage"...

C'est plus compliqué que celà. Gitan, c'est une ethnie. Gens du voyage, c'est un style de vie. Il se trouve qu'en France, les deux correspondent. Mais le distingo est, à mon sens, important : parle-t-on du peuple Gitan, ou de gens qui ont besoin d'eau et d'electricité à raccorder à leur caravane? En bref, parle-t-on en termes ethnologiques/politiques, ou en termes techniques? Dans un cas, on parlera de Gitans, dans l'autre de gens du voyage. Même si ce sont les mêmes.

[Johnny P.]

Mon idée est que l'utilisateur final ne sait pas utiliser un ordinateur ou bien le programme qu'il est supposé , utiliser.

Et tu te rends compte , que le programme fait autre chose , ce pour ce qu'il a été fait.

Il faut penser à tous les scénarios d'erreurs et des fois c'est choquant de se rendre compte , ce qu'on fait de son application , la verrouiller de tous les côtés est la solution et ça rend la tâche complexe.

Sans parler que les informaticiens connaissent mieux le travail que l'utilisateur final... et ça rend les choses plus délicates.

[mumen]

Je comprend bien ce que vous voulez dire en disant il faut prendre les utilisateurs pour des imbéciles, mais cette formulation est erronée, fautive, tordue. Elle peut amener à mal penser son métier.

Si vous tenez effectivement à exprimer quelque chose de contre productif et de très difficile à assumer dans notre métier de créateurs d'interfaces elles même au service de nos fabuleux outils, utilisez alors le terme d'ignorants pour qualifier les utilisateurs. Pas d'imbéciles.

[gaby277]

Bonjour,
Je suis surpris que seuls le développeur et l'utilisateur final soient évoqués. Je m'explique normalement il y a un "cahier des charges" qui décrit les fonctionnalités que doit avoir le logiciel. Il y a ensuite en tout cas pour les gros projets et (ou) vitaux pour l'entreprise des essais de réception du logiciel. J'ai fait ça à une époque. La (les personnes) chargés des essais rédigent ensuite un document qui liste les anomalies constatées, les non conformité au cahier des charges, les autres travaux repris au cahier des charges par exemple notice utilisateurs, analyse fonctionnelle , sources si cela est prévu tout cela est vérifié .Cela conditionne la réception ou non du produit et donc éventuellement ou non le paiement du solde et de la retenue de garantie ...(quand on touche au portefeuille ...)

J'ai eu a réceptionner des softs ou des que cliquais sur un bouton ça plantait,
L'informaticien corrigeait mais pour certains pour un bug corrigé il en créait 2 autres sur des parties déjà testées ... Je n'en ai pourtant pas déduit que tous les informaticiens étaient des idiots.
Il peut également y avoir des essais plus techniques par exemple d'essais de saturation du système, de robustesse à par exemple de déformation de messages, de changement de calculateurs si les systèmes sont doublés de tolérances de pannes etc ...

Je m'étonne que rien de tout cela soit évoqué..

Par ailleurs le "ce sont tous des idiots" est prétentieux. Que l'informaticien se dise bien que son garagiste, son chauffagiste, son médecin, son moniteur de ski peuvent tout autant le prendre pour un demeuré puisque sur une technique particulière ils connaissent plus de choses.

Je conclurai par le classique "un peu de science enfle, beaucoup de science désenfle". Je pense que ça s'applique particulièrement à l'informatique et que prendre les autres pour des idiots n'est pas une preuve d'intelligence mais bien au contraire de médiocrité.

[mumen]

Bonjour,
Je conclurai par le classique "un peu de science enfle, beaucoup de science désenfle". Je pense que ça s'applique particulièrement à l'informatique et que prendre les autres pour des idiots n'est pas une preuve d'intelligence mais bien au contraire de médiocrité.

Oui mais non !

Le débat qui a lieu ici, ce n'est pas de prendre les gens pour des idiots, mais de faire semblant de les prendre pour des idiots alors qu'on pense pas que ce sont des idiots parce que l'on pense que pour faire un bon programme, il faut se mettre dans la peau d'un utilisateur qui ferait n'importe quoi, un idiot en somme (faire semblant de se prendre soi même pour un idiot) . Tu vois la nuance ?


En fait tu amènes de l'eau à mon moulin, cf mon poste juste avant le tien. C'est un problème de vocabulaire mal placé. Il faut se situer au niveau de l'ignorance, pas de l'ineptie pour se faire comprendre dans cette problématique. Ce choix sémantique devrait d'ailleurs avoir une incidence sur la manière de faire les choses. C'est un autre sujet.

[Simplifi]

Bin, moi j'ai de la chance!
mes utilisateurs sont tout à fait intelligent(e)s, même les blondes!!!
ils ou elles ne demandent que des vraies améliorations!!
Il est vrai que dans chaque entreprise où je vends ma petite solution ERP, je fais obligatoirement une formation Access, tous et toutes ne deviennent pas développeurs mais cessent de penser que l'informatique est magique!
Ah, au fait, je donne la base de mon ERP à qui le veut.

[mumen]

Bin, moi j'ai de la chance!
mes utilisateurs sont tout à fait intelligent(e)s, même les blondes!!!
ils ou elles ne demandent que des vraies améliorations!!
Il est vrai que dans chaque entreprise où je vends ma petite solution ERP, je fais obligatoirement une formation Access, tous et toutes ne deviennent pas développeurs mais cessent de penser que l'informatique est magique!
Ah, au fait, je donne la base de mon ERP à qui le veut.

je fais obligatoirement une formation Access

Tu as compris comment gagner de l'argent en développant !

cessent de penser que l'informatique est magique

Et tu obtiens le beurre en plus de l'argent du beurre !

Ah, au fait, je donne la base de mon ERP à qui le veut.

Belle attitude . Je suis preneur : j'adore regarder le travail des collègues, l'ERP est plus ou moins mon coeur de métier depuis plus de vingt ans et je développe sous Access.

[Simplifi]

Merci pour le précédent message
cette version de 8Mo est la copie de celle que j'utilise tous les jours pour mon compte personnel.
D'autres versions, utilisées par mes clients, sont basées sur le même fond de panier et elles ont des fonctions dont je n'ai pas besoin:
- configurateur de devis
- table des références produits (dans le conseil, c'est superflu)
- gestion de stock (mon stock de conseils est infini )
- gestion de fabrication, ordres de fabrication, fiches de réglage
- bordereaux de livraison

Toute personne assez compétente peut l'utiliser, il faut jute commencer par le gestionnaire de table attachées.

J'en ai aussi une qui sert seulement à calculer la TVA sur les fleurs. Elle est aussi gratuite et facile à utiliser et comme elle est plus petite, elle est en pièce jointe

[Daranc]

Bon je pense qu'on à tellement dilué le sujet, que le sens du vrai problème nous file entre les doigts: La finalité c''est qu'on doit simplement se méfier des évidences. Déjà avec les Normes ISO 900x il y avait une petite annotation qui disait que 50% de ce qu'on dit n'est pas enregistré ( je vous laisse faire le cacul de ce qui reste en troisième main) mais qu'en écrit on arrivait à un résultat pas aussi mauvais (mais presque) sauf que c'était toujours en première main. A la limite celui qui sait réellement ce dont il a besoin, c'est celui qui est sur le poste! au final ce n'est pas l'utilisateur qui est en porte à faux mais toutes la chaine de conception qui lui délivre un produit non adapté. Soit trop technique, Soit trop touffu, soit carrément ch.. (euh! politiquement correct.. alors) Laxatif à utiliser, d'un ennui mortel. La'informatique c'est bien quand on s'éclate devant un PC mais quand on s'y emm... à tapez des tartines insipides à longueur de temps

[djibxav]

D'après mon expérience, bien plus qu'un idiot, l'utilisateur à 99% est un fainéant de première.

J'ai, dans une récente expérience automatisé au maximum des tâches.

Et bien les même utilisateurs qui appliquaient des règles métiers propres à leur savoir faire, une fois ces règles automatisées, ne savaient plus rien faire.

Au moindre cas particulier et donc devant se gérer en partie à la main, sur une règle qu'ils appliquaient sans problème avant, ils se trouvaient perdus et on entendait "l'informatique gère pas ce cas, je sais pas quoi faire".

Le pire c'est qu'on est les premiers responsables de ce trait des utilisateurs qu'on dénonce.
Plus on automatise, et réduit les utilisateurs à des pousse-boutons, plus ils se formatent intellectuellement, à pousser des boutons sans réfléchir.

L'informatique loin de libérer les utilisateurs en automatisant le rébarbatif, leur laissant plus de temps pour réfléchir, les rend idiots, en leur enlevant toute activité neuronale quotidienne.

[Invité]

Quelles idées avez-vous de l'utilisateur final lors du développement d'une application ?

… Le développeur doit faire le maximum d'efforts pour comprendre son « client ». Certains diront même qu'il faut aller jusqu'à se mettre dans la peau de l'utilisateur final pour produire une solution attrayante, cohérente, intuitive et facile à prendre en main.

Bonjour,

Je m’immisce tardivement dans cette discussion…

Je vous propose ma vision de développeur-fonctionnaire sur le sujet.

J’ai déjà abordé certains aspects de ma démarche de développement dans d’autres discussions mais le sujet de cette discussion, du moins l’extrait que j’en cite est en quelque sorte à l’origine de cette démarche que j’ai mise en pratique durant mes 37 années de carrière, de 1971 à 2007.

Conscient, dès mes premiers développements, des difficultés de communication développeurs-utilisateurs que traduit la célèbre caricature des balançoires, j’ai décidé de me rapprocher le plus possible de l’utilisateur jusqu’à développer in situ, tel un écrivain public. Pas d’intermédiaires, pas d’étude préalable, ni cahier des charges, ni dossiers d’analyse… Tout en « live », direct du développeur à l’utilisateur final.

A mon avis, l’un des gros problèmes de communication développeur-utilisateur vient du choix de l’interlocuteur-utilisateur. En effet, l’interlocuteur-utilisateur en question est généralement le responsable de l’entité (service ou division de gestion) qui connait certes les règles de gestion mais dont la fonction n’est pas leur mise en œuvre, dévolue à ses gestionnaires. L’intégration éventuelle d’un(e) gestionnaire dans une équipe de développement n’a en fait pas vraiment pour objectif de recueillir son avis mais de faire accepter la future application à l’ensemble des gestionnaires en leur faisant croire qu’elle a été validée par l’un(e) des leurs. Au final, le développeur s’appuie sur les règles de gestion transmises par l’utilisateur-responsable pour informatiser leur mise en œuvre, autant dire pour réinventer le métier de l'utilisateur, comme le disaient Guilip et Richard.

En m’installant parmi les gestionnaires, je vois et je comprends tout. Pas besoin d’interviews, de user-stories d’autant que le plus souvent, les gestionnaires ne savent pas qu’ils savent. Eka808 disait avec juste raison : « La plupart des utilisateurs connaissent leur business, ils savent ce qu'ils veulent mais ne savent pas l'exprimer. »

La responsable d’une entité de gestion que j’informatisais « Au Pied Levé - A main Levée » m’a dit un jour s’être étonnée, au début, que je ne lui demande rien et avoir eu très peur. Finalement, ayant constaté que tout se passait bien, elle m’a laissé faire. L’informatisation de sa problématique m’a occupé pendant une quinzaine d’années.

Il n’a sans doute pas été facile pour cette responsable de me voir m’afférer avec ses gestionnaires en l’ignorant presque et en voyant les échéances arriver, sans droit à l’erreur, alors que les fonctionnalités étaient en cours de création ou n’existaient pas encore. Les gestionnaires attendaient leur tour pour m’exprimer leurs besoins et repartaient le plus souvent avec la solution à leur problème. Me voyant travailler 12-15 heures par jour, parfois 24 heures ou un week-end entier, la responsable me disait : « vous savez, on peut faire à la main, on a fait ça jusqu’à l’année dernière ». Je lui répondais : « pas du tout, ne vous inquiétez-pas, je serai prêt ! » Évidemment, je ne prenais pas le temps de déjeuner, je piochais dans mon bocal de bonbons. Comme elle disait, trois smarties et je tenais la journée. Parfois, une gestionnaire me ramenait une pomme.

Le soir, passée l’heure officielle de la fin de journée, les gestionnaires changeaient complètement d’attitude. N’étant plus officiellement sous l’autorité de leur chef, elles se libéraient, et imaginaient de nouveaux besoins à partir de ce que je leur avais déjà concocté. L’instant ne durait pas très longtemps car la plupart des gestionnaires sont des femmes, pressées de rentrer chez elles pour récupérer le gamin à la crèche, faire quelques courses, etc. Pour moi, c’était le début d’une deuxième journée, je restais souvent jusqu’à trois heures du matin pour leur faire ce qu’elles avaient évoqué et le matin, elles trouvaient le résultat sur le coin de leur bureau. L’important pour moi était de gagner, de conserver leur confiance, de ne jamais les décevoir.

Avec le temps, les responsables me laissaient gérer certains problèmes d’intendance avec leurs gestionnaires, ce qui leur permettait de se consacrer davantage à leurs occupations liées à leur fonction.

Finalement, j’avais autant de chefs de projet que de gestionnaires et je n’étais en somme, qu’un traducteur. Nul besoin de créer un manuel puisque je respectais leur façon de travailler. Par contre, je leur proposais des outils simples qui leur permettaient de créer elles-mêmes leur propre documentation si elles en éprouvaient le besoin. Quelque chose d’un peu plus sophistiqué, par exemple que la touche « Impécr ». Chaque gestionnaire créait ainsi sa propre documentation. Je la leur empruntais de temps en temps pour comprendre leur besoin d’information et améliorer éventuellement mon application.

Chaque nouvelle gestionnaire apprenait le métier grâce à l’application et avait pour mission d’apporter sa contribution afin de mériter son nom au générique de l’application. Un item de l’application permettait d’afficher ou de lister toutes les personnes ayant participé au développement, sous forme d’un générique, comme pour les films.

Un jour, une collègue, chef de projet, passait dans la division que j’ai informatisée. Je lui propose de lui montrer comment ça fonctionne et je l’emmène dans le bureau des Karine. C’est un bureau de quatre gestionnaires qui s’appellent toutes « Karine ». Je fais les présentations et commente leur travail, lorsque abordant une fonctionnalité, une karine se manifeste pour soulever un problème, les trois autres surenchérissent immédiatement à la limite de l’agressivité. Je calme le jeu en leur promettant de résoudre le problème dans le ¼ d’heure et je sors avec ma collègue. Grand silence… puis ma collègue me dit, stupéfaite : « tu as vu comment elles te parlent ? » Je lui réponds : « elles me parlent normalement, c’est comme ça que je les ai éduquées. Elles ont raison, je n’ai pas été pertinent et ça va me coûter une boîte de chocolats, au pire un resto. C’est le tarif ! »

L’une des Karine a refusé deux fois le bénéfice d’un concours. « Jamais je retrouverai ailleurs une telle ambiance de travail » disait-elle. Bien que s’étant dispersées au fil du temps, parfois dans d’autres administrations, toutes ces gestionnaires restent en contact et continuent de se voir.

De ma façon de développer (bottom-up), j’en ai tiré un certain nombre de constantes, parfois surprenantes comme celle concernant mon espace de travail. Je n’y avais jamais prêté attention mais en fait, je n’ai jamais occupé un espace de travail normal avec un bureau normal, une fenêtre et une porte donnant sur un couloir. S’installer chez les gestionnaires avec son serveur n’est pas prévu dans l’organisation administrative. Autrement dit, c’est le système D. J’ai eu beaucoup recours aux encombrants dont on pouvait se débarrasser une fois par mois sur les trottoirs. En 37 ans de développements, les anecdotes abondent…

Un jour tout de même, la responsable d’une entité de gestion m’a proposé de m’acheter un vrai bureau grâce à un reliquat budgétaire, pour remplacer mes deux tables d’opératrices de saisie récupérées dans un sous-sol. Plus basses d’environ 8-10 cm qu’un bureau normal pour compenser la hauteur des claviers de l’époque, je les avais rehaussées sur des cales de bois. Du coup, j’ai réfléchi à ce qui pouvait me convenir le mieux pour faciliter mes échanges avec les gestionnaires. J’ai opté pour deux bureaux en « L » accolés pour former un « T ». Les plans formant la barre horizontale faisaient 80 de profondeur ; les plans formant la barre verticale faisaient chacun 60 cm de profondeur et se terminaient par un plan en demi-cercle. Ainsi, je disposais de deux postes de travail, le mien et un autre à disposition d’un utilisateur. Mon bureau servait également de petite salle de réunion.

Bon, je parle et si ça se trouve, ça n’intéresse personne, c’était dans un autre monde, à une autre époque. Vous pouvez reprendre vos activités normales.

A suivre, peut-être !...

[souviron34]

Bon, je parle et si ça se trouve, ça n’intéresse personne, c’était dans un autre monde, à une autre époque. Vous pouvez reprendre vos activités normales.

Si si continue....

Enfin quelqu'un d'autre

En dehors de nos expériences différentes et néanmoins convergentes, je retirerais de ton pavé 2 ou 3 choses que je pense particulièrement utiles pour nos "collègues" plus jeunes ici présents :

j’ai décidé de me rapprocher le plus possible de l’utilisateur jusqu’à développer in situ, tel un écrivain public. Pas d’intermédiaires, pas d’étude préalable, ni cahier des charges, ni dossiers d’analyse… Tout en « live », direct du développeur à l’utilisateur final.

Sans aller jusqu'à ces extrêmes (tu semblais avoir une "clientèle" captive), ce que je prône à longueur de threads s'appelle "user-centered design", avec en particulier une tête de projet bi-céphale (un utilisateur-expert et un généraliste informaticien) et une interaction permanente - une approche "agile" dans le vrai esprit, sans la méthodologie.

A mon avis, l’un des gros problèmes de communication développeur-utilisateur vient du choix de l’interlocuteur-utilisateur.

Tout à fait, ce qui est totalement négligé la plupart du temps..

L’intégration éventuelle d’un(e) gestionnaire dans une équipe de développement n’a en fait pas vraiment pour objectif de recueillir son avis mais de faire accepter la future application à l’ensemble des gestionnaires en leur faisant croire qu’elle a été validée par l’un(e) des leurs.

Absolument essentiel..

d’autant que le plus souvent, les gestionnaires ne savent pas qu’ils savent.

Cela va beaucoup plus loin que les gestionnaires.. Les utilisateurs c'est pareil, et les formateurs itou..

D'où l'intérêt d'une approche user-centered, où l'ergonomie (par exemple en interviewant, filmant, les utilisateurs au travail) est essentielle..

Je l'ai prouvé à une Directrice de la Formation d'une boite équivalente EDF à l'étranger, où nous avons filmé des représentants clientèles, et elle était avec moi, et elle a découvert que sur certains formulaires 1/3 des cases ne servaient pas ou n'étaient jamais remplies, les employés faisant les calculs de tête d'une part et d'autre part sachant que 99.99% des cas tombaient dans la case xx direct..

Dans un autre cas, en médecine, alors que les comités de consultation avaient conclut qu'il fallait un outil de recherche dans les dossiers, qui, sans plus, avait été réparé comme une recherche normale, nous avions filmé un cardiologue lisant des - très gros - dossiers de patients venant depuis longtemps à l'hopital : des dossiers de 600 pages il les lisait en 3 minutes... Mais surtout, TRES intéressant, sa recherche était chronologique UNIQUEMENT pour le dernier séjour à l'hopital. Pour les séhours plus ancins, c"était en sens inverse... Sans l'avoir filmé, personne ne l'aurait su...

Nul besoin de créer un manuel puisque je respectais leur façon de travailler.

Tout à fait.. L'objectif doit être : "zéro formation"....

De ma façon de développer (bottom-up),

C'est à mon humbe avis également la seule vraie manière de procéder, tout au moins hiérarchiquement...

Et c'est à mon avis aussi l'explication d'un grand nombre de cas d'échecs retentissants (Socrate à la SNCF par exemple, qui dans ses premières années a été un échec cuisant)

La hiérarchie top-down n'est qu'un nid à emm.rdes, et un potentiel de mauvais choix...

[el_slapper]

(.../...)
La hiérarchie top-down n'est qu'un nid à emm.rdes, et un potentiel de mauvais choix...

Et pas seulement pour la conception de l'interface. Ca vaut aussi pour les choix techniques. Chez mon nouveau client, la direction a retropédalé après 5 ans d'investissements massifs dans un nouveau produit, parceque 7% de la volumétrie mettaient déjà la nouvelle appli à genoux, alors que l'ancienne tourne bien. L'objectif était de "moderniser la technologie"...

Pour l'interface, ça me rappelle un vieux projet. L'année précédente, l'une des 30 antennes régionales, celle de Marseille, avait recruté un stagiaire pour faciliter une tache administrative en pleine expansion. Ledit stagiaire avait fait un truc sympa, avec les moyens du bord(EXCEL), calé au milieu des 6 intervenants marseillais. Mais, pour industrialiser plus - et étendre aux autres régions - il fallait un vrai programme en central.

Excellente décision fut prise de (1) faire un programme(JAVA, en l'occurence), qui automatisait encore plus, accessible par toutes les régions, mais surtout (2) de reprendre le stagiaire(pour son PFE) dans l'équipe de développement à Paris. Nous avons donc eu, dans l'équipe de développement, un expert métier(il avait passé 4 mois à les observer), qui était stagiaire. Et ça a très bien marché.

[Ecva233]

Je suis en accord complet avec vos derniers posts, le seul souci, c'est que cette approche n'est plus dans l'air du temps. Car cette approche redonne un pouvoir énorme finalement à la "couche" la plus basse en terme hiérarchie, et la moins noble (le coté pisseur de ligne).

Pensez un simple analyste se permettrait de pondre des services utiles à l'utilisateur final, sans avoir de référent info fonctionnel, d'architecte logiciel, de référent MOA, de coordinateur MOE, de représentants MOA, MOE, sans méthode particulière, juste en s'appuyant sur la logique et le bon sens ...
Vous voulez la mort de beaucoup de parasites. En plus vous allez faire monter le chômage d'un seul coup, et la valeur de certains diplômes va en prendre un coup !

Vous n'y pensez pas que diable

[Invité]

Aucun risque ! Cela suppose d’être libre de ses mouvements et dans sa tête, de penser par soi-même, d’avoir cherché sa propre vérité, d’être autonome, pluridisciplinaire, de prendre des risques, d’adopter ce que j’appelle une véloce attitude. Cela ne s’enseigne pas, j’ai vérifié ; à 35 ans, j’ai fait trois ans de formation continue à l’IUT (A mon époque, les DUT-Informatique n’existaient pas encore. Les recrutements d’informaticiens se faisaient à l’aide de tests psychotechniques suivis d’une entrevue avec d’autres tests devant un psychologue. Ces épreuves ne se passaient qu’une seule fois et en cas de réussite, elles ne donnaient seulement que le droit de passer un concours ; après, c’était formation chez le constructeur).

Ah, si ! J’y ai rencontré un enseignant sublime. Son discours était très philosophique, mes collègues de formation continue n’y comprenaient rien, ils attendaient des recettes, il nous demandait de réfléchir. Il n’a jamais prononcé le nom d’une quelconque méthode. Un jour, il nous a concocté un DST dans lequel il posait une question intéressante : il s’agissait, à partir d’une petite description de Base de Données et d’un ensemble de besoins utilisateur, de concevoir l’écran approprié (on dirait IHM, peut-être aujourd’hui ?). Nous étions une trentaine, j’ai été le seul à proposer l’écran attendu. La correction a duré une heure pendant laquelle le prof a décortiqué le cheminement intellectuel ayant motivé ses choix. Du grand art ! J’ai eu l’impression de vivre une psychanalyse. Je ne suis pas un spécialiste du recrutement, mais à mon avis, ce genre d’épreuve révèlerait beaucoup de choses.

Pour ma véloce attitude, je vous expliquerais bien mais je vais m’écarter du sujet.