Il est difficile de mesurer la qualité d’une intégration. Certains outils comme le validateur W3C ou des validateurs WCAG permettent de se faire une petite idée, mais ne sont en rien représentatifs de tous les critères concernés par l’intégration d’une page web (graphisme, référencement, développement, etc…).
En y réfléchissant, je pense que la qualité d’une intégration peut se mesurer sur 3 niveaux avec les questions suivantes :
- Est-ce que c’est bien pour l’internaute ?
- Est-ce que c’est bien pour le projet ?
- Est-ce que c’est bien pour moi ?
La première question, « Est-ce que c’est bien pour l’internaute ?« , fait directement écho à mon mantra. En se préoccupant d’abord de l’internaute, on va faire attention aux problématiques qui vont directement le toucher :
- La performance : la vitesse de chargement d’une page web est un des critères les plus importants vis-a-vis de l’internaute. Est-ce que mon code est bien optimisé ? Est-ce que mes images sont bien découpées et bien compressées ? Est-ce que le nombre de requêtes HTTP est bien optimisé ?
- La compatibilité : vu la multitude d’appareils, de navigateurs et de logiciels permettant d’accéder au contenu de votre site, il est indispensable de codez pour les autres. Est-ce que la propriété X fonctionne sur le navigateur Y ? Est-ce que ma page s’affichera bien sur de nouveaux appareils avec des résolutions d’écran 2 fois supérieures ?
- L’accessibilité : toute aussi importante, et pourtant souvent sous-évaluée. Est-ce que le code un peu filou que je suis en train d’écrire sera bien interprété par un navigateur vocal ?
La deuxième question, « Est-ce que c’est bien pour le projet ?« , s’attache aux particularités de votre projet.
- Le type de projet : on n’évalue pas la qualité d’une intégration d’un e-mail, d’une application Facebook et d’un site e-commerce de la même manière. Les bonnes pratiques de l’intégration d’e-mails sont à l’opposé des bonnes pratiques d’un site e-commerce. Différentes problématiques demandent donc différents regards d’évaluation.
- Le graphisme : trop souvent vu comme la finalité d’une page web, il n’en reste pas moins un critère important. Est-ce que votre intégration ressemble bien à la maquette ? Est-ce que vous avez du prendre certaines libertés ? (et si oui, est-ce vraiment parce que c’est mieux pour le projet ?)
- Le référencement : selon le type de projet, il est possible que vous ayez des impératifs forts en référencement. Certaines préconisations vous demanderont peut être d’aller à l’encontre de vos bonnes pratiques habituelles.
- La technologie utilisée : même en livrant une intégration HTML statique, vous n’obtiendrez jamais le même résultat selon le langage (PHP, .NET, Ruby, …) ou le CMS (WordPress, Magento, …) utilisés par votre projet.
La dernière question, « Est-ce que c’est bien pour moi ?« , est le moment de penser à vous, cher intégrateur, mais aussi à vos collègues intégrateurs. C’est le moment de vous posez des questions sur vos pratiques personnelles.
- La compréhension de votre code : est-ce que vous arriverez à comprendre ce que vous venez d’intégrer dans 1 an ? est-ce que vos collègues vont comprendre ce que vous venez de faire ?
- La pertinence de vos choix d’intégration : j’ai intégré toute ma page en « position:absolute ». Est-ce que c’était vraiment la meilleure solution ? Et si jamais on doit changer ça dans 3 mois ?
- Les bonnes pratiques habituelles : si vous travaillez en agence, il est important de respecter les normes d’écriture et les bonnes pratiques habituelles. Si votre agence utilise toujours jQuery, est-ce bien raisonnable d’utiliser Mootools parce que « vous aviez envie d’essayer » ?
Ce ne sont ici que quelques exemples, et les tenants et aboutissants de l’évaluation de la qualité d’une intégration sont évidemment bien plus nombreux. Mais ces quelques critères permettent déjà de prendre un certain recul sur son propre travail, et surtout de relativiser sur son jugement du travail des autres.
Nico, le
De sages conseils. J’ajouterai même dans « Est-ce que c’est bien pour moi ? » le conseil suivant : est-ce que je suis fier ? Est-ce que mon code est propre, élégant, efficace ?
Sinon, côté accessibilité : est-ce que l’ordre logique de lecture hors CSS est pertinent ? (très souvent oublié celui-là, et pourtant fondamental pour plein de choses)
Question qualité, sachant que mon intégration risque d’être malmenée, j’essaie toujours d’avoir des exigences très élevées au moment de faire le template CSS de base. Je pars de l’idée qu’il faut partir de très haut d’entrée de jeu.
sacripant, le
Il est parfois difficile de juger le travail effectué par l’intégrateur au travers du résultat final.
Travaillant avec des devs Drupal (qui je soupsonne un poil fainéant ou ne maitrisant pas trop la partie theming), je suis souvent désabusé par le code généré.
Si le rôle d’un intégrateur est de respecté au maximum la conception du designer/ergonome, celle d’un développeur n’est-elle pas également de respecter le travail effectué par l’intégrateur, quel que soit l’outil utilisé ?
0gust1, le
Merci pour ce billet qui incite à prendre un peu de recul et de contextualiser le travail d’intégration.
J’ajouterais aussi qu’un intégrateur ou un developpeur web ne travaille pas toujours en agence, sur des projets full-internet : il y a aussi le monde merveilleux des applicatifs « intranet » (surtout, ne sous-estimez pas le volume et l’importance de ce « segment de marché »), qui a bien besoin aussi de qualité dans le « front-end », mais pas forcement avec les mêmes critères et priorités qu’un projet internet.
@sacripant : à la décharge de tes devs Drupal : le theming Drupal est assez difficile à prendre en main (c’est un euphémisme…) : http://pioupioum.fr/developpement/drupal7-angoisse-theming.html
Draeli, le
Ce que tu n’évoques pas, c’est les contraintes qui parfois amènent à des paradoxes entre « le bien pour l’internaute » et « le bien du projet ».
En tant qu’intégrateur, je pense d’abord aux visiteurs, à ceux qui devront utiliser ce que l’on créé, cependant parfois le projet de part ses différentes contraintes (ici je pense qu’on a chacun nos exemple à apporter !) amène à des incohérences ou malgré tout la bonne volonté, il a du code « dirty », du code « alarache », des incohérences d’accessibilité afin de faire des contournements à des fins abominables.
Donc pour moi juger de la qualité d’une intégration est très complexe et généralement la solution que j’ai trouvé à ca est de voir directement avec la personne qui a intégré et lui poser les questions pour voir quels ont été ses critères, pourquoi elle a fait tel ou tel choix et surtout par rapport à ce dialogue voir ce qu’elle pense elle même de son intégration.
D’une manière général, j’ai remarqué que les intégrateurs passionnés ont la fâcheuse tendance à être très critique envers eux mêmes et être un peu « jusqu’au-boutiste », ce qui en soit n’est pas un mal car cela permet de toujours se remettre en question (comme tu l’as évoqué comme dans ton précédent billet).
Ma conclusion sur ce point reprend donc tes trois questions mais surtout de garder un caractère impartial et toujours être capable de se poser des questions !
Bartdude, le
@Draeli > je pense que tu soulignes toute la différence entre la qualité de l’intégration et la qualité de l’intégrateur. Il y a plein de choses qui peuvent avoir un impact négatif sur une intégration, et les contraintes dont tu parles (envie du client qui même sans argument reste le roi, budget, timing, …) qui font que mêmes les meilleurs intégrateurs produisent parfois du code dont ils ne sont pas forcément fiers, mais qui est le meilleurs possible en tenant compte de ces contraintes.
En fait cette remarque peut aussi faire office de réponse à sacripant : les développeurs doivent aussi faire avec ces contraintes et l’incompétence ou la fainéantise ne sont pas forcément les seules raisons expliquant que le code produit soit différent de l’intégration prévue.
Très chouette synthèse ce billet cela dit, dommage que trop souvent les premières questions qu’on doive poser en agence est « quel est le budget ? » et « pour quand cela doit-il être fait ? »…