Comment mettre en place un contrôle qualité pour votre projet Web ?

En effet, en recherche constante de la maîtrise des coûts, de la gestion des risques et d’un réel retour sur investissement, il n’est pas absurde d’appliquer au digital des principes qui ont fait leurs preuves depuis longtemps dans l’industrie « non-numérique ».

Dans ce contexte de fabrication, la « qualité » est un concept bien défini qui recouvre des méthodes et outils pour aligner la production avec des exigences déterminées pour le produit fini. Il parait évident, dans un projet Web, mobile, digital, que les livrables doivent aussi correspondre à des exigences, fixées en fin de chaîne par les utilisateurs eux-mêmes.

Dans cet article, nous abordons la pratique de la qualité à un niveau technique. Il s’agit de mettre en lumière les enjeux et les outils qui se présentent à une équipe de développement.

Définir la qualité d’un projet de développement

La « qualité » absolue n’existe pas. Elle se définit par rapport à une référence. C’est ce référentiel que doit maîtriser une équipe de développement avant toutes autres choses.

En fait, il s’agit même de maîtriser plusieurs référentiels concernant différents aspects du projet. Il peut s’agir de la qualité du code source, mais également de la qualité de l’expérience utilisateur, ou même encore de la qualité de l’accessibilité numérique d’une page d’un site pour les publics en situation de handicap, etc.

Ainsi, c’est de la responsabilité de l’équipe de développement de mettre en place les référentiels « qualité » qui vont concerner la production des livrables techniques. Ces référentiels doivent être toutefois choisis en réponse à d’autres enjeux qualité de plus « haut niveau ». Par exemple, des exigences « qualité » doivent être mises en place au niveau du code source pour satisfaire à celles d’un référentiel d’éco-conception global au projet...

Aussi, la « qualité » doit être dimensionnée. Pas la peine d’embarquer des référentiels de qualité qui ne sont ni pertinents, ni utiles. La « sur-qualité » est une « non-qualité ». L’on choisit également en priorité des référentiels « qualité » qui font « référence » (sic), ou au moins « consensus » parmi les acteurs du Web. Ils sont à la fois un gage de crédibilité et à la fois d’efficacité. Ils s’attachent à des éléments tangibles, réels, sans sur-qualité justement.

Les référentiels peuvent être à géométrie variable. Non qu’il s’agisse de transiger avec la qualité (ce serait tout à fait contraire à l’esprit même de la « qualité »), il s’agit de « doser » l’effort de qualité pour obtenir le meilleur rapport bénéfices/coûts. Ainsi par exemple, un référentiel d’accessibilité numérique tel que RGAA (à lire également notre article sur : Comment garantir l’accessibilité numérique de votre site Web ?) connait plusieurs niveaux d’exigences.

« Référentiels de qualité » et « normes » sont synonymes. Adimeo ayant une très forte expérience et expertise en matière de commande publique, nous sommes confrontés à des exigences majeures en termes de normes, certaines mêmes imposées par la législation. Ceci induit une grande responsabilité dans la pratique de la qualité de ces projets. Qualité qui concerne autant le développement technique, que l’UX et l’UI Design et même la gouvernance.

Le schéma ci-dessous indique les référentiels auxquels les marchés publics nous confrontent (Référentiel Général de Sécurité, d’Intégration, Pidila qui est un référentiel qui en synthétise d’autres, …) et que nous intégrons dans une démarche où chaque critère « qualité » bénéficie aux autres critères, dans un cercle vertueux.

Au niveau du développement, l’intégrabilité de chaque référentiel n’est pas en prise directe avec la production du code source. Parmi ceux mentionnés dans le schéma ci-dessus, OWASP, W3C, S.O.L.I.D. sont trois référentiels qui concernent en premier lieu l’équipe de développement.

La sélection puis l’application, de référentiels et de normes pour son projet va donc déterminer tous les points à soigner lors de l’implémentation. Et donc tous les points à vérifier lors de la livraison. Car en effet, la « qualité » est un principe qui fixe des exigences, mais aussi un principe de vérification systématique de la satisfaction de ces mêmes exigences. Dès lors, que contrôler ?

Que contrôler en cours d’implémentation ?

Plusieurs aspects de l’activité d’une équipe de développement sont concernés par la « qualité ». Nous en donnons ici un inventaire qui permet de construire sa propre démarche qualité.

Le code source

Le code source est le « matériau » principal du développement. À côté du produit fini et fonctionnel, il constitue souvent également un livrable du projet. La qualité du code source en elle-même est un socle pour toute la démarche de qualité.

Un code source de qualité conditionne notamment la maintenabilité et l’évolutivité du projet digital. Les critères « qualité » portent donc ici sur des conventions d’écriture du code source qui facilitent les opérations de maintenance et d’évolution. En un sens, le code source doit être facile à lire et facile à comprendre.

Ceci étant un peu subjectif, il existe des critères objectifs (impératifs pour un référentiel digne de ce nom) qui peuvent être évalués comme élément de qualité. Depuis les conventions de nommage des variables jusqu’à la complexité cyclomatique d’une méthode, des critères permettent de valider la qualité du code source écrit. Qu’on parle ici de « bonnes pratiques », ou de « coding standards », pour chaque technologie/langage, il existe des listes de critères déjà quantifiés qui sont faciles à intégrer à son référentiel qualité du code source.

La micro-architecture

Juste au-delà de la qualité d’écriture du code, il y a la qualité de la structuration du code. C’est un critère indispensable pour garantir aussi la maintenabilité et l’évolutivité du code source. Et on peut même affirmer que la qualité de la micro-architecture conditionne aussi la sécurité, la fiabilité et la performance du site ou de l’application à développer.

On contrôle ici la capacité des développeurs à tirer le meilleur parti des possibilités de la programmation orientée objet par exemple. Pour chaque technologie, il y a un état de l’art à connaître et à mettre en œuvre pour atteindre un niveau de qualité suffisant. Si la tâche n’est pas toujours simple, des « guides » sont disponibles et ont fait leurs preuves : S.O.L.I.D. par exemple, ou d’autres design patterns.

La performance et la sécurité

Si les deux concepts sont sans rapport direct, ils sont à considérer comme des éléments importants des contrôles « qualité ». Si importants qu’on doive déterminer des critères spécifiques et des points de contrôles tout autant spécifiques. La performance et la sécurité sont également liées à la micro-architecture. Ils en sont mêmes de items critiques qui demandent une attention particulière.

La couverture en tests automatisés

La couverture en tests automatisés est un critère « méta » de la qualité du code source. En effet, on verra au chapitre suivant que les tests automatisés et les linters sont les outils nécessaires au contrôle de la qualité dans un projet. La présence de tests automatisés, leur généralisation et leur efficacité à vérifier la qualité du code source est donc une (méta)donnée pertinente de qualité elle-même.

Le delivery

Il s’agit ici d’évaluer la « qualité » des livraisons en bout de chaîne. Un faible taux de livraison refusée (quelle qu’en soit la raison) est un bon critère d’évaluation d’une bonne qualité sur les autres points évoqués ci-dessus. Au contraire, trop de livraisons infructueuses indiquent des non-qualités potentielles à chaque étage : code source, architecture, etc.

Se doter dès la phase de développement de bons outils est déterminant pour la pratique de la qualité. Ce sont ces outils qui sont à la fois les garants de l’efficacité et aussi de la productivité de la démarche qualité des développeurs.

Quels outils pour effectuer ces contrôles ?

La qualité s’appuie sur des outils qui facilitent sa mise en œuvre. Dans la pratique du développement ces outils viennent aider les développeurs à bien comprendre les enjeux concrets liés à la qualité et vérifier qu’ils ont répondu scrupuleusement aux exigences de qualité.

La documentation

L’outillage passe d’abord par une documentation solide. En début de projet, il est nécessaire de rassembler en un document « unique » l’ensemble des référentiels « qualité » appliqués. Il doit être possible de se référer en permanence à la documentation pour vérifier, comprendre, appliquer un critère qualité.

Les outils pour documenter la qualité n’ont rien de spécifique par rapport à d’autres outils de knowledge management. Un wiki, compléter par un moteur de recherche efficace et pertinent peut très bien faire l’affaire.

Une chose importante dans cette gestion de la connaissance, c’est le rôle qu’on attribue à un développeur de l’équipe / de la mêlée (le lead par exemple) comme garant de la bonne documentation des référentiels « qualité ». Un critère de qualité, pris brut depuis son référentiel, demande parfois de la pédagogie pour bien en comprendre le sens et le domaine d’application. Avoir un « responsable qualité » au niveau d’une équipe technique s’avère efficace.

L’environnement de développement intégré (IDE)

Premier outil du développeur, l’IDE est une aide précieuse et surtout un outil de productivité. Un IDE digne de ce nom doit intégrer les critères qualité qui portent sur le code source de la technologie que l’on utilise au quotidien.

Selon la spécialisation dans un langage, l’IDE embarque tout ou partie des référentiels en vigueur. Par exemple, chez Adimeo, le développement PHP/Symfony se fait avec PHPStorm qui vérifie la conformité du code source produit avec les normes de PSR. L’IDE permet de configurer les critères qualité, et de construire, par configuration, les siens propres.

Les tests automatiques

Intégrés à l’IDE, en standard ou par extension, les outils d’analyses statiques, ou linters, viennent compléter les outils de vérification « temps réel » de la conformité. Depuis les conventions de nommage, jusqu’à la « complexité » du code en passant par la couverture en tests unitaires, ces outils sont les gardiens vigilants de la qualité du code source. On peut se reposer sur eux et les compléter avec ses propres critères / outils.

Pour une « non-qualité » récurrente dans un projet, on peut mettre en place son propre outil de contrôle automatique pour vérifier spécifiquement ce « point de douleur ». Dans l’industrie, ce principe s’appelle un poka-yoke, un principe de lean manufacturing incitant chaque « ouvrier » à se fabriquer, par l’expérience, des petits outils de contrôle qualité très efficaces.

Conclusion : intégrer la qualité au projet

En conclusion, on comprend que la qualité, dans un projet de développement, est à la fois une démarche, une pratique et des outils.

La qualité concrète du projet repose toutefois en grande partie sur l’extrémité de la chaîne de production que constitue une équipe de développement. Une grande responsabilité pèse donc sur les développeurs et sur leur capacité à « mettre en œuvre » encore plus que « respecter » les critères qualité.

Cette mise en œuvre doit être intégrée à chaque phase du projet et systématiquement appliquée au moment critique du projet : la livraison. Les outils de qualité, notamment, les outils automatiques ont donc toute leur place dans la chaîne d’intégration et de déploiement continue. Comme c’est le cas pour les tests unitaires, les tests d’API, ou d’acceptation.

Et au-delà du poste de développement et de la responsabilité du développeur, la qualité concerne toute la chaîne de production des livrables. Une équipe technique est là aussi pour se prononcer sur la qualité d’un produit conçu et bientôt à réaliser.

Crédit photo : Blue Planet Studio