Billet fantôme 1 : Le front-end architecte

Je vous ai écrit dernièrement que je pensais publier des articles billets incomplets sur mon site, question de les faire vivre un peu, même si j’ai manqué d’énergie / d’intérêt pour les terminer. Qui sait, peut-être qu’avec votre aide, je pourrais les compléter. Je vous les laisse sous licence libre (documentation GPL).

Le premier est un article que je prévoyais essayer de faire publier par un vrai newsletter. Après quelques réécritures et discussions avec des gens de mon entourage, j’en suis venu à la conclusion que je n’arrivais pas à expliquer le sujet comme il faut, ce qui faisait que l’objectif même de l’article semblait un peu utopique. Puis j’ai cessé de vouloir devenir un architecte front-end pour être un architecte technique conventionnel (j’ai eu le temps de parfaire mes connaissances en back end depuis 😉 )

La dernière version de cet article a été écrite un peu avant la présentation du Combo sur la qualité à Intracom Québec 2008. Pour ceux qui y était, vous allez y voir des liens.

Sans plus tarder :

L’architecte de présentation : un rôle clé dans les projets Web ?

Pourquoi les projets Web de grande envergure sont si difficiles à gérer technologiquement ?
Les dépassements de budget et des fonctionnalités limitées par rapport aux attentes sont malheureusement choses courantes dans ce type de projet. Pourtant, les technologies de base formant un site Internet sont relativement simples, mais le sont-elles vraiment ?

Dans cet article, nous allons faire un tour d’ensemble de toutes les préoccupations et défis techniques reliés à la présentation d’une application Web et cerner le niveau de complexité de ceux-ci. Nous allons ensuite valider si l’ajout d’un nouveau type de ressource, l’architecte de présentation, peut aider à gérer cette complexité.

Avec l’avènement du Web 2.0 et des interfaces utilisateurs riches de la compétition entre sites Web pour une bonne place dans les moteurs de recherche, le rôle d’un site Web n’est plus seulement de présenter des documents statiques aux utilisateurs. Et même lorsque c’est le cas, ceux-ci doivent présenter plusieurs qualités pour qu’ils aient la chance de rejoindre les internautes de façon efficace.

Chaque solution technique répondant à une préoccupation reliée à une métrique de succès a de fortes chances d’avoir un impact sur un autre aspect technique. Et malheureusement, cet impact est souvent négatif. Par exemple, le choix d’une plate forme technique d’intégration qui améliore la productivité des développeurs peut rendre pratiquement impossible l’accessibilité et un bon placement dans les moteurs de recherche. Une technique qui augmente le placement dans un moteur de recherche à court terme, peut briser la structure des documents, être potentiellement incompatible avec le gestionnaire de contenu et diminuer la maintenabilité de ceux-ci. Par contre dans certains cas, ces solutions sont viables. Il est nécessaire de bien connaître les impacts des choix technologiques et s’assurer que ceux-ci maximisent le potentiel du succès du projet. Pour ce faire, il est nécessaire d’aller plus loin que la technique. Des connaissances en ergonomie, en design et en communications sont utiles. Il faut faire le lien entre ces disciplines et celles d’architecture conventionnelles. Il est nécessaire dans une application Web d’envergure d’avoir le juste millieu entre toutes les demandes techniques de façon à ce que les choix respectent le budget, la qualité, le temps de développement, la maintenabilité et les orientations courts et longs termes du projet et du client.

Voici quelques préoccupations qui touchent à la couche présentation ou frontale d’une application et qui doivent dans la plupart des cas couvertes lors de l’analyse et du développement d’une application ou d’un site Web.

La maintenabilité : Nous parlons ici de s’assurer que les choix technologiques et la méthodologie de développement facilitent l’évolution du projet Web et minimisent les coûts d’opérations de celui-ci. Certains compromis sont parfois faits entre la rapidité initiale du développement et la facilité de mises à jour par la suite.

L’architecture d’information : La cueillette et l’organisation des informations et ressources disponibles sur un site application ou portail doit faciliter la recherche et favoriser l’accès rapide. Cette activité requiert des connaissances différentes de l’informatique, du design et de l’ergonomie, même si elles sont complémentaires et très interreliées.

L’utilisabilité : L’ergonomie des interfaces utilisateur est

[Incomplet]

Ajouter une citation d’un spécialiste en utilisabilité.

Lorsque le Web devient la plate forme principale de communication avec vos clients et employés, l’accessibilité et l’utilisabilité deviennent incontournables.

L’accessibilité : L’accessibilité est l’une et une des plus grandes forces du Web.
L’accessibilité veut entre autres dire que les fonctionnalités du site Web doivent rester utilisables même si l’utilisateur final possède un handicap quelquonque. On parle souvent des aveugles, mais on oublie de penser au daltonisme, aux problèmes d’ouie, de mobilité (utilisation de la souris) et aux problèmes légers au niveau cognitif. L’accessibilité, c’est bien plus que de faire fonctionner un site Web avec un lecteur texte (quoi que c’est un bon départ).

On peut parler ici de dégradation élégante : les fonctionnalités restent les mêmes, mais elles requièrent parfois plus d’étapes, sont simplifiées et leurs visuels moins complexes.

Note : Ajouter une citation d’un spécialiste en accessibilité

L’optimisation pour les moteurs de recherche (SEO) : La plupart des internautes utilisent les moteurs de recherche pour retrouver les contenus et les sites de commerce électronique sur le Web. Pour tout type de site ou application Web, l’optimisation pour les moteurs de recherche est devenue primordiale. Ceci est tout aussi vrai pour les applications internes en entreprise qui sont parfois difficiles à retrouver et à utiliser à l’intérieur de portails. L’évolution des techniques est très rapide, entre autres puisque les charlatants et les pourriposteurs essaieront toujours de manipuler les moteurs de recherche.

Le respect des conventions et normes du Web : Celles-ci peuvent s’appliquer en utilisabilité comme au niveau du protocole réseau. Par exemple le soulignement qui signifie un lien ou les conventions REST au niveau des services Web et savoir quelle norme de HTML ou XHTML choisir.

Gestion de conversations entre l’utilisateur et l’application : Les exemples les plus simples sont les formulaires s’échelonnant sur plusieurs pages. Toutes les applications Web comportant le concept de connexion ou de session doivent gérer des conversations. Les plus complexes amènent les applications Web à ressembler à des applications bureautiques et client serveur conventionnelles.

La sécurité : Quand on parle sécurité, nous pensons généralement à la protection de nos bases de données et à l’intégrité de nos serveurs. Or, la plupart des failles de sécurité se retrouvent sur les interfaces utilisateurs et les attaques se font vers les utilisateurs du système plutôt que vers les serveurs. On parle ici de failles comme le Cross Site Scripting et le Cross Site Request Forgery. Même plusieurs attaques conventionnelles, comme celle de l’injection SQL, passe par la couche présentation avant de se rendre aux bases de données. Certaines technologies, comme Ajax offrent aux bidouilleurs de nouveaux vecteurs d’attaques. La gestion des mots de passe, questions secrètes, authentification et autorisation, se passent aussi dans les interfaces utilisateurs. L’impact peut être important sur l’utilisabilité d’un système.

La gestion de contenu : L’objectif des outils de gestion de contenu est de rendre la maintenance et l’évolution d’un site Web ou d’une application Web possible par des personnes qui ne connaissent ni les conventions du Web, ni la programmation Web. Le défi ici est à deux niveau, il est nécessaire de s’assurer que les créateurs de contenu et les approbateurs puissent bien utiliser le gestionnaire et s’assurer qu’aucune entrée de contenu puisse briser le site ou l’application Web. Or les utilisateurs sont habitués à pouvoir contrôler directement l’apparence de leurs documents, en particulier avec des outils comme Microsoft Word, ce qui en soi peut causer beaucoup de problèmes d’intégration. Les données entrées dans un gestionnaire de contenu, qui gèrent l’ensemble des menus, liens entre contenus, pages, images, contenus dynamique et autres éléments riches peuvent devenir si complexes, que même les meilleures bases de données peuvent y perdre leur latin.

L’intégration de progiciels : On parle ici d’outils comme des applications de commerce électronique, des rapports d’utilisations, etc. Ces progiciels sont très utiles, car ils peuvent diminuer le temps de développement et augmenter la productivité des développeurs d’applications complexes et transactionnelles. Le défi des développeurs est d’intégrer ces produits tout en respectant les préoccupations de la couche présentation de l’application Web. Ces produits dans leur configuration de base ignorent souvent l’optimisation pour les moteurs de recherche, l’accessibilité et le respect des standards ouverts Web. Il est important de bien connaître les impacts en termes de développement du produit final.

Plates formes, modèles de développement et patrons de travail : Dans le cadre d’architecture orientés services par exemple, si le HTML servant à construire les pages de l’application proviennent de plusieurs sources. Le contenu statique peut venir d’une source et le contenu applicatif d’une autre. il est nécessaire de s’assurer de la compatibilité du HTML de chacune de ces sources ou prévoir une transformation préalable.

L’envoi de courriels :La compatibilité avec les divers moteurs de courriels en lignes (HotMail, Yahoo, GMail,etc) est en soit un sujet complexe que même les standards du Web ne peuvent complètement assurer. La problématique que les courriels ne doivent pas être considérés comme étant du pourriel. (SPF, configuration serveur de courriels). Encore une fois, le design du courriel, les textes utilisés ainsi que les configuration serveurs et réseaux ont tous un impact sur la bonne réception des courriels.

Interface de programmation Web 2.0 et Services Web : En effet, l’intercommunication entre sites et applications Web nécessite d’envoyer des messages en format javascript ou en services Web conventionnels (SOAP). Une connaissance ici des protocoles de communication utilisés en Ajax (JSON) et javascript sont nécessaires.

Le Web mobile : On parle ici de versions épurées des interfaces Web utilisés sur les téléphones cellulaires, les organisateurs personnels et les nouveaux gadgets mobiles comme le iPhone et les nouveaux iPod. Dans le type de projets visant ces utilisateurs les questions comme la dégradation élégante ou s’il est nécessaire d’avoir plusieurs versions du site Web vont se poser. Cela a un impact du design au choix des patrons de travail en passant par le gestionnaire de contenu. Certaines technologies, comme Flash et Java, ne sont pas toujours disponibles et lorsqu’elles le sont, ce ne sont pas les mêmes versions que sur le Web conventionnel. Les questions de compatibilité et d’interopérabilté se posent ici.

Les applications riches Internet (RIA) : Plus encore que les applications Web 2.0 les RIA font converger les applications bureautiques standards comme Word ou Outlook et les applications Web. Les prochaines versions des navigateurs offriront certaines fonctions rendant les RIAs de plus en plus puissantes. Pensons aussi aux produits comme Adobe Air et Silverlight de Microsoft qui entrent dans la mêlée.

L’assurance qualité : Un effort particulier doit être fait au niveau de l’assurance qualité. La dichotomie application Web et document Web fait parfois que la perception de simplicité des documents Web diminue le temps de tests alloué aux sections moins dynamiques d’un site. Plusieurs outils existent pour aider à tester les applications, ceux-ci doivent être bien intégrés au projet et ne remplacent pas les tests exécutés par des humains, particulièrement au niveau de l’utilisabilité.

L’analyse d’utilisation : Après l’implantation d’un site, il est judicieux de vérifier si les Internautes utilisent bien le site et quelles sont les pages les plus populaires du site. L’analyse de ces données servira à prioriser les prochaines étapes d’amélioration du site et de marketing. Plusieurs outils existent pour faciliter cette tâche. L’analyse des données peut toutefois vite devenir complexe pour les plus grands sites et une attention particulière doit y être faite. Si les opérateurs d’un site Web ne savent pas si celui-ci sert vraiment et s’il est apprécié, il sera difficile de justifier les efforts pour l’améliorer et l’utiliser à sa juste valeur.

Nous avons qu’effleuré plusieurs aspects du développement de site et applications Web et il en existe plusieurs autres. Chacun de ceux-ci individuellement pris peuvent parfois être simples, mais vus ensemble, ils peuvent devenir une source de complexité difficile à gérer.
Il est nécessaire de valider les recommandations dans l’une ou l’autre de ces préoccupations lorsque celles-ci proviennent de spécialistes qui ne connaissent pas les impacts de celles-ci.

Plusieurs de ces éléments sont parfois gérés par un architecte technique, organique ou de données d’un système. Ces architectes ont toutefois d’autres préoccupations aussi importantes (performance, intégrité des données, productivité des développeurs) qui vont parfois prendre le dessus sur la plupart des préoccupations reliés à la présentation. Les connaissances des architectes conventionnels ne couvrent souvent pas ces techniques et leur complexité risque d’être parfois ignorée. Lorsqu’ils le sont, la valeur d’un site ou d’une application Web peut être fort diminuée et même suffire à transformer un projet qui semble en bonne route en un échec.

Un nouveau type d’architecte

Nous avons déjà des architectes de données, (DBA) des architectes d’infrastructure, des architectes organiques et des architectes d’information. Plusieurs experts pensent qu’il est maintenant temps de spécialiser un autre type d’architecture : l’architecture de présentation, architecte frontal ou front-end architect en anglais.

L’architecte de présentation est responsable d’assurer un suivi sur tous les aspects dont nous avons présenté ci haut. Il est un lien très important entre l’humain, le besoin d’affaire et la technologie Web. Il peut, selon le besoin d’affaire, mettre plus d’emphase sur un élément d’architecture de présentation. Au même titre que les autres architectes, il conseille le chef de projet sur les décisions à prendre. Dans certains cas, il peut même représenter le client au niveau technique puisque celui-ci doit avoir une bonne connaissance des interfaces utilisateur et de l’ergonomie. L’architecte de présentation défini la stratégie de gestion de contenu, les stratégie de tests unitaires et fonctionnels de la couche de présentation. Il définira les normes de réalisation selon les besoins réels du projet. L’architecte de présentation est responsable de la gestion des connaissances sur tous les éléments qui impactent la couche de présentation Web et s’assure qu’aucun choix technologique n’ait d’impacts négatifs sur les réalisations.

L’architecte de présentation est en général un développeur Web senior, il peut provenir autant des équipe de programmeurs Web ou des graphistes Web.

L’avènement des architectures orientés services et d’application par couche séparent les préoccupations dorsales, frontales et données, la spécialisation au niveau de l’architecture devient possible et dans plusieurs cas souhaitable. Étant donnée l’importance accrue des applications Web, il est nécessaire d’avoir de plus en plus une stratégie à moyen ou même long terme sur les choix technologiques et la qualité et dans ce sens, l’architecte de présentation est une ressource clé pour définir cette stratégie.


L’article a encore besoin d’être retravaillé, il faudrait peut-être le couper en plusieurs partie. Le public cible de l’article n’est pas toujours clair non plus. Il est toujours mieux ici que dans le fond de mon disque dur…