| La
phrase qui tue | "Vous devez respecter des spécifications très précises du poste de travail" |
| Les doctrines,
principes, pratiques NTI | Certains progiciels webisés exigent tel ou tel navigateur et dans une version supérieure à x.xx. Certains progiciels webisés exigent un logiciel navigateur précis et en version x.xx. Pour les runtimes Java, il y a aussi des spécifications variables selon les logiciels. |
| Le
point de vue du client, le vécu de l'utilisateur | Les
NTI ne sont donc pas aussi universelles qu'on veut bien le dire. L'utilisateur
en entreprise comprend difficilement les restrictions imposées par le
projet de système d'information NTI, par comparaison avec ce
qu'il connaît de l'Internet au travers de sa connexion à
domicile. Exemple. L'utilisateur qui prend l'initiative de modifier certains paramètres internes de son navigateur ou simplement d'utiliser un raccourci qu'il a créé vers une page d'un portail risque des déconvenues du type refus de connexion ou même des affichages incohérents. Par manque de temps et du fait de l'obscurité de la documentation des paramètres internes des navigateurs, il est probable que les "bogues" repérées par cet utilisateur audacieux seront versées dans la catégorie des "non reproductibles" et qu'il recevra la punition de la réinstallation intégrale de son poste de travail. Et si l'entreprise doit un jour faire évoluer ses postes de travail, bonjour les complications.... Au total, on en revient à l'époque où chaque application avait son serveur propre et ses terminaux ? |
| La
phrase qui tue | "La barre d'outils de l'application est bien distincte de celle du navigateur, chez nous personne ne se trompe jamais" |
| Les doctrines, principes, pratiques NTI | Il faut 6 mois pour maîtriser un framework de programmation, alors.... |
| Le
point de vue du client, le vécu de l'utilisateur | Pour
l'utilisateur, la
confusion
entre le bouton de retour arrière du navigateur et celui de
l'application est inévitable. Pourtant, l'effet peut être très différent, est-il normal de rejeter la faute sur l'utilisateur ? |
| La
phrase qui tue | "Ce n'est pas un défaut, notre framework de programmation est fait comme cela" |
| Les doctrines,
principes, pratiques NTI | Dans certains cas, lorsque l'utilisateur vient d'opérer un choix dans la liste de sélection, il replie la liste sur la valeur choisie dans le champ concerné, mais tant que le "focus" reste sur ce champ, la roulette de la souris fait encore défiler les valeurs de la liste. |
| Le point de vue du client, le vécu de l'utilisateur | Instruit pas l'expérience,
après
chaque sélection dans une liste, l'utilisateur
s'astreint à un clic
supplémentaire systématique hors
champ avant de passer à autre
chose... vive
le progrès. NB. Cette discrète intrusion de l'aléatoire dans les dialogues est réservée aux audacieux, mais peut-être en bénéficiez-vous sans le savoir, cherchez bien ! |
| La
phrase qui tue | "C'est natif en mode web" |
| Les doctrines,
principes, pratiques NTI | La génération des écrans d'interaction est automatique dans un environnement intégré de programmation et permet de respecter uniformément la charte graphique des couleurs souhaitées |
| Le
point de vue du client, le vécu de l'utilisateur | Les dialogues
d'interaction créés
dans un environnement de programmation suffisent à la rigueur en
première vérification d'une logique
informatique, mais ne constituent pas un dialogue
optimisé
d'interaction et, sauf cas très simples, s'avèrent inutilisables en
usage courant. Pourquoi ? Lourdeur des dialogues d'interaction avec des régénérations intempestives de l'affichage et en gros un doublement du nombre de clics nécessaires par rapport à une saisie classique en client-serveur, Temps de réponse variables et longuets (dus aux appels répétés aux bases de données et au chargement des scripts d'affichage), Difficulté de représenter des liaisons logiques entre ensembles successifs d'informations saisies (nécessitant un rappel d'informations dépendant du contexte), Impossibilité (?) des retours en arrière pour corrections partielles dans une séquence de saisies, Etc ! Comment peut-on croire qu'une modélisation "objet" peut produire des logiques de dialogue utilisables ?!! |
| La
phrase qui tue | "Les temps de réponse de la plate
forme de test ne sont pas
significatifs, il seront bien meilleurs sur la plate forme
d'exploitation avec plus de mémoire" "De toute façon, votre réseau n'a pas la bande passante suffisante" |
| Les doctrines,
principes, pratiques NTI | Pour améliorer les temps de réponse d'une application, on augmente la mémoire des serveurs pour augmenter la taille des caches |
| Le
point de vue du client, le vécu de l'utilisateur | Le
résultat est
chaotique, parfois l'utilisateur constate une
réponse immédiate du système, parfois un temps de réponse plus que
sensible, pour des raisons inexplicables (en fait chaque
fois que
sa demande ne correspond plus à une page préstockée). Pour l'utilisateur, le temps de réponse normal en mode web c'est celui des moteurs de recherche sur l'Internet au grand large, à partir de son domicile avec un débit bien inférieur à celui du réseau d'entreprise. Il comprend mal... |
| La
phrase qui tue | "Nous allons gagner un facteur 5 en temps de réponse; à présent, les applications vont être compilées pour le multiprocessing et l'option déboguage sera désactivée" |
| Les doctrines,
principes, pratiques NTI | Des serveurs multi processeurs, des
capacités généreuses de mémoire,
des
réseaux à grande capacité, etc, etc |
| Le
point de vue du client, le vécu de l'utilisateur | Même le poste de travail
de
l'utilisateur n'est pas épargné. Car les jolies pages
interactives en mode web, c'est encombrant et il faut de la
mémoire et de la puissance locales pour les afficher. Les NTIC, même sans parler des coûts de développement et de mise en place, ce n'est vraiment pas gratuit ! |
| La
phrase qui tue | "Vous ne pouvez pas raisonner sur la définition d'un seul flux d'échange pour dire qu'il manque une donnée" |
| Les doctrines,
principes, pratiques NTI | Dans une architecture intégrée cohérente, tous les flux d'échanges entre applications passent par l'EAI générique et chaque flux correspond à un objet normé |
| Le
point de vue du client, le vécu de l'utilisateur | Vu
de
l'utilisateur, on peut trouver que les fonctions externes d'un EAI
sont inférieures à celles d'une messagerie paramétrable et que
cet
intermédiaire ne fait que tout compliquer sous un obscur fouillis de
haute technicité. On peut douter de l'intérêt des fonctions internes de mapping dans l'EAI, censées économiser du travail aux applications, mais qui d'un autre point de vue renforcent l'illusion qu'elles se comprennent du moment que les champs sont transmis informatiquement en XML. Des fichiers journaux informatiques bruts sont insuffisants vis à vis du besoin de vérifier facilement l'envoi et la bonne réception entre deux applications. On peut aussi mettre en cause le besoin d'une communication en pseudo temps réel entre les applications. La plupart des échanges peuvent attendre au moins quelques heures, ou alors il s'agit d'un worflow et dans ce cas pourquoi ne pas utiliser un moteur spécialisé dans ce type de gestion en workflow à la place d'un EAI générique ? Enfin, la décomposition des communications interapplicatives en flux élémentaires normés au sens des bases de données peut sembler artificielle. En tous cas, cette décomposition complexifie considérablement la mise en cohérence logique des données dans chaque application réceptrice (dans le cas où le problème est traité, évidemment...), car cette vérification exige pratiquement de prendre plusieurs "objets" reçus pour reconstituer à grand frais l'entité signifiante d'origine de l'application émettrice. Dès lors, ne serait-il pas préférable de définir chaque flux d'échange inter applications plus simplement sur la base des ensembles de données valides au sens de l'application émettrice ? La modélisation de décomposition normée de ces ensembles en objets élémentaires servirait alors seulement aux vérifications de cohérence au départ et à la bonne interprétation à l'arrivée, mais surtout pas à une décomposition physique en flux élémentaires. Le constat est que, sous prétexte de NTI, on modélise le système d'information comme si la cohérence des données pouvait être assurée a priori. Sans le dire, on piétine le principe de conception de l'architecture logicielle et matérielle en modules faiblement connectés (c'est à dire que les flux d'échange entre modules applicatifs doivent rester à faible fréquence et que chaque module applicatif gère la cohérence des données qu'il utilise ou crée). Il ne faut pas s'étonner alors que les mises au point d'un système d'information NTI semblent infinies ET que la plupart des problèmes rencontrés apparaîssent comme des détails; c'est que la conception NTI est un modèle d'insignifiance par construction, où l'"architecture modulaire" ne dépasse pas le niveau de la " programmation orientée objet" si chère à nos maîtres, mais bien piètres architectes ! |
| La
phrase qui tue | "En mode web, il faut trouver des astuces pour le transactionnel" |
| Les doctrines,
principes, pratiques NTI | Le middleware détecte et compense les défauts de transmissions des paquets dans les réseaux TCP/IP. Les 4/5ème des documents descriptifs des standards du web sont consacrés à ces questions. En revanche, il n'existe aucun standard pour gérer des sessions transactionnelles de travail à distance. |
| Le
point de vue du client, le vécu de l'utilisateur | Dans un Intranet d'entreprise, est-il sensé
d'espérer traiter les rares cas particuliers de mauvaise transmission
des paquets par un intermédiaire aveugle sur la signification
des données transportées ? La réalisation d'un mécanisme de SSO (Single Sign On) permettant à un utilisateur de donner une seule fois son mot de passe pour accéder à un ensemble d'applications semble encore relever du bricolage, certes bien emballé dans un discours doctrinal. Et si on faisait un peu d'analyse de la valeur ? |
| La
phrase qui tue | "C'est un principe de Qualité" |
| Les doctrines,
principes, pratiques NTI | La gestion des accès aux bases de données est un sujet archi connu. Cette gestion fait d'ailleurs la différence entre les systèmes de bases de données simples et les systèmes "industriels" |
| Le
point de vue du client, le vécu de l'utilisateur | Les mécanismes complexes d'exclusion des accès aux
bases de données sont-ils toujours pertinents et utiles ? Par exemple, lorsqu'il s'agit des documents d'une équipe de projet, si DD ouvre un document en écriture, il paraît suffisant qu'un signal "DD travaille" empêche tous les autres candidats de modifier ce même document (il peuvent tout de même le lire en sachant que "DD travaille"). Autre exemple. Dans les cas où le traitement d'un document se déroule selon une séquence prédéfinie (workflow de traitement de facture par exemple), les droits d'accès sont automatiquement attribués selon le rôle tenu par chacun au stade considéré de la séquence. Un mécanisme simple d'accès suffit largement. Dans tous les cas, si la personne qui travaille sur un document s'endort dessus ou part faire autre chose, les autres candidats doivent attendre, que la gestion soit complexe ou simple.. Pourquoi donc ne pas envisager d'abord des techniques simples plutôt que d'imposer a priori des mécanismes coûteux qui ne seront utiles qu'une fois sur cent, mille, un million.... ? |
| La
phrase qui tue | "Nous attendons depuis 6 mois le modèle de votre base source et la fourniture d'une base de test pour terminer la réalisation de l'automatisme de reprise" |
| Les doctrines,
principes, pratiques NTI | Modélisations des bases sources et cibles, mapping des champs source-cible, automate de reprise, etc |
| Le
point de vue du client, le vécu de l'utilisateur | Avant de
pouvoir reprendre les données dans une nouvelle application qui
remplace une application existante, il est nécessaire que les
utilisateurs fassent évoluer leurs données sources pour les
rapprocher du modèle cible et
les rendre conformes aux référentiels communs. Cette mise à niveau préalable est en soi un projet, il est douteux qu'elle puisse être automatisée. Dès lors, il sera prudent de limiter l'automate de reprise à des transferts "simples" que l'on pourra effectuer si possible en une seule passe au moment du basculement final. Noter que, pour certaines applications, les historiques représentent un capital (exemple : gestion de maintenance) qu'il est crucial de reprendre, en vérifiant la continuité des indicateurs calculés sur ces historiques entre l'ancienne et la nouvelle application. Dans d'autres cas, par exemple les données concernant des affaires en cours ou des prévisions, pourquoi ne pas envisager une reprise manuelle au moins en partie, plutôt qu'une reprise automatique ? Les utilisateurs peuvent y trouver leur compte, en se formant à la nouvelle application et de plus il est plus facile d'initialiser des données que de les mettre à jour dans un nouveau contexte. |
| La
phrase qui tue | "Vos utilisateurs n'essaient même pas de mettre en oeuvre le système" |
| Les doctrines,
principes, pratiques NTI | Les fonctions "métier", les cas d'utilisation sont modélisés |
| Le
point de vue du client, le vécu de l'utilisateur | L'utilisateur, c'est celui qui met
en oeuvre un système d'information dans son métier quotidien. L'utilisateur n'utilise pas ce qu'il ne comprend pas. L'utilisateur met mal en oeuvre ce qu'il rejette pour diverses raisons. L'utilisateur est imparfait, il se trompe souvent... L'utilisateur emploie un logiciel pour les buts et selon les méthodes qu'il s'approprie. Ce ne sont pas toujours exactement ceux prévus à l'origine d'un projet. Les NTI servent bien à augmenter les capacités des utilisateurs ? |