| La
phrase qui tue | "Le bogue provient de l'application d'origine" |
| Les doctrines,
principes, pratiques NTI | Encapsulez votre application existante dans un environnement web et intégrez la sans souci dans votre nouveau système d'information |
| Le
point de vue du client, le vécu de l'utilisateur | La webisation d'une application de la vie
réelle ne se fait pas sans douleur, et il existe un gros risque
d'impasse terminale. Techniquement : les dialogues d'interaction sont profondément modifiés pour passer en mode web, la logique interne de travail avec l'ancienne base des données est refondue car l'ancienne base est remplacée par une autre plus moderne. Donc au total, il s'agit d'une transposition difficile, pour laquelle il faudra recourir aux experts connaissant le fonctionnement technique de l'ancienne application. Autres facteurs non techniques : l'utilisateur profite de l'occasion pour exiger des améliorations fonctionnelles de l'application initiale; il les exprime à partir de l'application telle qu'il la connaît c'est-à-dire l'ancienne... Le projet de webisation devient donc de fait un projet de refonte, ce qui augmente considérablement le risque d'un résultat décevant et d'une bataille juridique. La moins mauvaise solution pour webiser une application existante est à choisir parmi les suivantes. S1. Conserver l'application maison telle quelle, l'exploiter au travers d'un canal web d'accès à distance, l'interfacer a minima par des interfaces brutes d'export/import en batch S2. Aligner le besoin sur un module de progiciel webisé sur étagère S3. Redévelopper l'application en NTI Concernant le choix S2 : prendre garde que certains progiciels webisés s'avèrent peu communicants, soit parce qu'ils contiennent une architecture web propriétaire secrète (car développée à grand frais), soit parce qu'ils conservent une architecture ancienne interfacée ponctuellement en mode web et incapable de s'ouvrir plus largement. |
| La
phrase qui tue | "C'est aux utilisateurs de dire ce qu'ils veulent" |
| Les doctrines,
principes, pratiques NTI | Phase d'élaboration = modélisation UML, formalisation des cas d'utilisation, ... |
| Le
point de vue du client, le vécu de l'utilisateur | Ce que le client utilisateur attend est bien
différent : simplement de savoir où il va et ce qu'il aura à
la fin, et sans être forcé de répondre à des questions techniques qui
ne le concernent pas. Une phase de définition doit prioritairement servir à repérer les risques qui empoisonneront le projet dans la suite, y compris et surtout les risques d'évolutions forcées des diverses NTI mises en oeuvre. Si, du côté de l'industriel réalisateur, les acteurs de la phase sont tous des seniors (ou des consultants ex-juniors qui vont quitter l'entreprise de conseil dans deux mois), on gaspille une opportunité d'instruire les juniors qui vont faire la réalisation dans la suite. Les spécifications détaillées sont trop souvent des reproductions plus que des productions. Tous les travaux qui produisent du papier sont à réduire au strict minimum au profit d'un vrai prototypage. |
| La
phrase qui tue | "Ou bien cela peut s'expliquer formellement ou bien cela n'existe pas" |
| Les doctrines,
principes, pratiques NTI | A partir d'un bon modèle, la réalisation est quasiment automatique |
| Le
point de vue du client, le vécu de l'utilisateur | Les méthodes de travaux pratiques en école
d'informatique doivent être adaptées en vue des réalisations dans le
monde réel. Telles quelles, ces méthodes s'appliquent à des cas complètement bornés et répétitifs. Si on introduit la dose naturelle d'imprévus et de nouveautés, le modèle implose, ou devient tellement complexe que seuls quelques spécialistes savent l'interpréter et dire comment on est censé l'utiliser. Et, après cet important effort, le risque est grand que la réalisation soit d'une ergonomie rebutante surtout si elle prend en compte d'un seul tenant l'enveloppe de tous les cas possibles. En fait, ce qu'il faudrait pouvoir modéliser dans un projet à forte dose de NTI, c'est le niveau de flexibilité des besoins en fonction de la stratégie de l'entreprise, afin de les mettre en relation avec les technologies mises en oeuvre, au lieu de réinventer l'eau chaude et de déployer des banalités en variantes infinies. En revanche, lorsqu'on admet l'impossibilité de représenter complètement le besoin par une méthode formelle, on peut utiliser des méthodes de modélisation avec grand profit, comme supports de réflexion, éventuellement comme supports de maquettage, mais pas plus. Car pour l'utilisateur, c'est toujours une représentation simplifiée, une forme d'aliénation, jamais il n'accepte de s'y reconnaître, il se méfie du modèle d'un monde futur à génération spontanée... Car il considère, lui l'utilisateur, qu'il fait partie du système d'information. |
| La
phrase qui tue | "Mais jamais vous n'avez demandé de pouvoir revenir en arrière dans ce type de dialogue !" |
| Les doctrines,
principes, pratiques NTI | Le prototypage consiste en pratique à mettre au point les écrans avec les utilisateurs autour de cas d'utilisation formalisés (puisque la modélisation formelle traduit le besoin et que la programmation ou le paramétrage réalise automatiquement la modélisation, etc, ) |
| Le
point de vue du client, le vécu de l'utilisateur | Au sens de
l'utilisateur, le vrai prototypage commence au moment où on le
laisse tester un
système complet par lui-même avec ses propres données, en faisant des
erreurs
et en jouant les perturbations de sa vie courante. Ce moment doit arriver aussi tôt que possible dans le projet. Toutes les applications doivent alors fonctionner ensemble. Les NTI permettent-elles oui ou non de raccourcir les délais pour en arriver là ? |
| La
phrase qui tue | "Votre demande est une évolution car elle n'est pas conforme au modèle" |
| Les doctrines,
principes, pratiques NTI | Modélisation exhaustive, prototypage des écrans, réalisation finale |
| Le
point de vue du client, le vécu de l'utilisateur | Plus la
réalisation issue des modélisations est optimisée au sens du
programmeur, plus elle
est globalisante et présente donc une tendance à l'obésité dans sa mise
en
oeuvre par l'utilisateur. Exemple : l'application de prise de commande oblige à passer au travers des mêmes écrans, pour la commande d'un client important bien connu dans le cadre d'un contrat cadre ou pour la commande d'un nouveau client à risques. Ce type de réalisation directement issue d'une modélisation globalisante est pour l'utilisateur une maquette, pas une application utilisable. D'où les demandes en "évolution". |
| La
phrase qui tue | "Nous avons passé tous les tests, il n'y a plus aucun bogue" |
| Les doctrines,
principes, pratiques NTI | Le modèle formel est correct, la programmation ne fait que représenter le modèle, il suffit logiquement que cela ne plante pas pour pouvoir affirmer que le logiciel est bon |
| Le
point de vue du client, le vécu de l'utilisateur | L'utilisateur
a l'impression d'un système piègé. Les fonctions les plus simples
semblent parfois requérir des ressources insoupçonnées
et présenter des risques d'erreurs. Il peut paraître
nécessaire
de retester les
calculs élémentaires avec diverses valeurs. Dans la logique d'un
programmeur pressé, la même
valeur 3,5
peut être arrondie une fois à 4, une fois à 3 dans deux champs du
même écran. |
| La
phrase qui tue | "Donnez-nous les numéros des flux qui sont passés dans l'EAI et les logs correspondants, sinon nous ne pouvons pas analyser le problème" |
| Les doctrines,
principes, pratiques NTI | La définition formelle des flux élémentaires est correcte, le moteur de l'EAI ne fait que traduire cette définition, donc il suffit de vérifier que les applications réceptrices reçoivent les données pour déclarer que les applications sont intégrées. (Sous-entendu non exprimé : c'est déjà un exploit technique de faire fonctionner ensemble plusieurs logiciels en environnement NTI) |
| Le
point de vue du client, le vécu de l'utilisateur | L'utilisateur
découvre
peu à peu... que les applications ne reçoivent pas toutes
les données
nécessaires à leur fonctionnement ou pas dans le bon ordre, ou ne les
interprètent pas
correctement. Plus tard, il va découvrir des incohérences
fonctionnelles entre les données envoyées par divers
flux d'échanges. Exemple classique : l'application A envoie vers l'application B un flux correspondant à une demande d'article en stock, mais l'application B ignore la demande parce que le demandeur noté dans le flux n'est pas un magasinier (l'application B a été conçue à l'origine comme une application indépendante avec sa propre base du personnel réduite au minimum utile), ou bien parce que l'article n'existe plus dans sa base depuis la veille. Alors, si aucun technicien spécialiste ne pense à examiner le "journal" informatique de l'application, toute trace de la demande est perdue. Des fichiers journaux informatiques bruts (logs) accessibles et exploitables uniquement par un spécialiste sont ineptes vis à vis du besoin de vérifier facilement l'envoi et la bonne réception entre les applications. |
| La
phrase qui tue | "Les flux d'échanges entre les applications ont été implémentés tels qu'ils ont été validés depuis x mois, c'est très compliqué de faire des changements maintenant" |
| Les doctrines,
principes, pratiques NTI | La définition de chaque flux est écrite en XML, tout est dit. |
| Le
point de vue du client, le vécu de l'utilisateur | Même une
modélisation rigoureuse des flux n'apporte aucune garantie de
cohérence fonctionnelle entre les applications car chaque
application
possède son propre modèle interne et interprète donc les champs à sa
propre façon. Exemple. Dans la modélisation interne d'un progiciel connu, le champ interne "code identifieur" correspond à ce qu'on appelle communément l'identifieur, alors que le champ "identifieur" correspond au libellé. A la place des noms-prénoms reçus d'une application de gestion du personnel, on a vu apparaître, sur tous les écrans du progiciel, des numéros de type sécurité sociale. |
| La
phrase qui tue | "La cohérence des référentiels, c'est le problème du client" |
| Les doctrines,
principes, pratiques NTI | Modélisation, architecture tout par l'EAI générique, cohérence automatique... |
| Le
point de vue du client, le vécu de l'utilisateur | Ce n'est pas si simple. Si l'on veut instaurer en priorité absolue la pureté des référentiels et des données dans un grand système d'information, la solution pratique "big bang" c'est la migration vers un progiciel intégré unique. A l'inverse, dans un système comprenant des applications d'origines différentes (exemple progiciels et anciennes applications maison) munies de leurs propres gestions des données, chaque application de fait porte et entretient ses propres référentiels. La gestion de la cohérence entre les informations référentielles répétées dans diverses applications nécessite une application transverse, en particulier pour rechercher régulièrement les écarts entre les informations contenues dans les applications par rapport à une norme commune définie, par exemple "sur telle information c'est telle application qui est maîtresse". Cette application transverse peut aussi gérer un stockage central dans lequel les applications viennent prendre les informations référentielles partagées dont elles ont besoin, notamment celles provenant de l'extérieur du système local, par exemple les clients dans un groupe multinational. L'évolution des référentiels (exemple : la segmentation des clients) ne doit pas perturber l'utilisation : par exemple, les utilisateurs ne doivent voir que des affichages issus des référentiels du jour même si les applications conservent des historiques fondés sur d'anciens référentiels. Pour y parvenir, il faut une réflexion préalable pour laquelle les beaux schémas ne disent rien. Il y a des conséquences sur l'architecture d'ensemble, sur les flux interapplicatifs, sur les applications... |
| La
phrase qui tue | "Il n'y a plus que 3 faits techniques de niveau bloquant, tout va bien" |
| Les doctrines,
principes, pratiques NTI | Une plate forme CMS permet un traitement
rigoureux des fiches de faits techniques |
| Le
point de vue du client, le vécu de l'utilisateur | Attention de ne pas se contraindre trop
tôt à
une gestion formelle de fiches de défauts via une procédure rigide
entre le client et les
développeurs. Les fiches et les procédures de faits techniques sont bien adaptées lorsque le système est stabilisé et que la courbe d'apparition des défauts de conception ou à fort impact devient asymptotique. A l'inverse, si on fige la procédure trop tôt, on alourdit les relations client-développeur jusqu'à l'exaspération, on atomise des problèmes qui devraient être traités globalement, on empêche la détection de défauts génériques dans plusieurs applications. D'autre part, un outil simple facilitant les imports-exports bureautiques peut s'avèrer préférable à un CMS. |