Le mot 'Qualité' est-il un gros mot dans l'IT ?

A la suite de mes interrogations sur la sécurité informatique, je constate quand même au fil du temps que la qualité n’est quasiment jamais au rendez-vous dans le domaine de l’IT.

Ce constat je le fais aussi bien en tant que professionnel du secteur travaillant selon les principes de la démarche DevOps et me trouvant donc à mi chemin entre le développement et l’opérationnel (historiquement, je viens de la partie Ops) qu’en tant que client utilisant le produit de services informatique d’entreprise.

Et ce n’est pas joyeux.

Dans le domaine professionnel, du côté Devs, j’ai rapidement compris et constaté que la qualité de service est la première chose sacrifiée au nom des sacro-saintes deadlines et autres budgets taillés à la tronçonneuse. Qu’est-ce que cela entraîne derrière ? De la perte de temps, des livrables qui ne fonctionnent pas, sont incomplets, blindés de régressions ou d’erreurs “normales”. Côté Ops, c’est l’incontournable Service-Level Agreement qui fait loi et plutôt que de résoudre un incident bloquant, on va voir comment refiler la patate chaude au plus vite ou penser en priorité à “vider sa backlog” plutôt qu’à rendre le service (aaah, combien de fois j’ai envie de frapper ceux qui n’ont qu’à la bouche cette directive, aussi bien insultante envers l’intérêt du client qu’envers la compétence de ses équipes en les rabaissant).

Le pire est qu’au nom des plannings, plutôt que de chercher à faire quelque chose de fonctionnel qui va créer de la valeur, la plupart des chefs de projets que j’ai pu côtoyer préféraient livrer dans les temps, peu importe la qualité finale. De toute façon ne c’était plus leur problème ensuite si l’application ne fonctionne pas bien en prod. Bordel, comment peut-on avoir une vision aussi étriquée du système d’information d’une entreprise ? Même chose du côté de l’opérationnel, plutôt que de s’assurer d’avoir un service de qualité, on va préférer des indicateurs qui font plaisir comme le nombre de tickets fermés. Et la réduction du nombre d’incident de manière proactive, on s’en moque ? Forcément, c’est moins vendeur et moins visible.

A mes yeux, j’estime qu’il y a une chose essentielle dans l’IT qu’on oublie souvent : le système d’information d’une entreprise est une vitrine de celle-ci auprès du client.

Ce qui est produit en matière de service informatique, c’est ce que les clients finaux utiliseront aussi en grande partie. Une enseigne commerciale qui n’est pas fichu d’avoir un site e-commerce fonctionnel passe pour une bande de guignols pour le client quand celui-ci a l’habitude d’un Amazon qui lui simplifie le parcours client de bout en bout.

Si je prends quelques exemples dans différents domaines.

Suivi de livraison de colis sur le site de La Poste : Une fois sur deux, j’ai une erreur dans la recherche du suivi (“suivi indisponible”). Le site est tellement bardé de trackers et scripts publicitaires en tout genre que la moindre ressource bloquée par µBlock Origin le déglingue entièrement. Quelle est l’intérêt du service si celui-ci est aussi instable ? Vous allez me dire : “tu n’as qu’à désactiver le bloqueur de contenus” (et ainsi se faire renifler le derrière en permanence, magnifique vision du Web)… Et bien même en session privée sans aucun add-on actif, ce site plante une fois sur deux.

Techniquement, le suivi d’un colis c’est une sélection en base de données utilisant comme identifiant un numéro de traçage, rien de plus. Est-ce devenu si compliqué de faire un select dans une table au point qu’il faille utiliser un amas de couches logicielles ?

Moins technique, la qualité de la donnée est aussi régulièrement négligée de mon expérience. Il suffit d’aller se balader dans n’importe quelle grande surface ou sur leur équivalent Web pour voir combien ils ne savent pas se mettre à la place de leurs clients. Cacophonie tarifaire (3 prix différents affichés pour le même article), “promotions” qui n’en sont pas, réductions de “0%” fièrement affichées, libellés complètement illisibles car intégrant bêtement ceux du fournisseur… Tout ceci témoigne d’une forte négligence de son système d’information. C’est pourtant pas difficile de mettre en place des contrôles qualité (il y en a déjà, mais quand ça arrange l’enseigne, au hasard le franchissement du seuil de revente à perte et compagnie). Mais quand derrière son système d’information est lui-même une cacophonie, que se passe-t-il ?

Dernièrement, j’ai vu passer une application développée pour faire des propositions de quantité de réapprovisionnement. Les règles de calcul sont relativement usuelles, basées sur l’état des stocks remontés par le backoffice des magasins, les ventes, et quelques autres règles de gestion. Mais en voyant l’intégration du logiciel, je découvre que ce dernier s’approprie la donnée “stocks” en la recalculant (par des règles de gestion que même “l’expertise” métier ne comprend pas) et la renvoyant en sortie au backoffice. De ce fait, il modifie l’état des stocks dans le backoffice alors qu’il n’a absolument aucune maîtrise de cette donnée ! Bravo, la donnée est devenue complètement faussée ! L’urbanisation et l’identification des systèmes maîtres de la donnée est pourtant là pour empêcher ce genre de cacophonie…

Pour continuer dans le domaine de l’expérience utilisateur, que dire des applications “modernes”. Un empilage de frameworks et de surcouches logicielles pour lesquels je me demande si le développeur maîtrise vraiment sa boîte à outils. Je ne leur jetterai de toute façon aucun disque dur dans la tronche, la root cause de ce genre de problème étant globalement liée au point des deadlines et budgets évoqués au début. Ou à la paresse technique des sociétés de service qui vont dire “nous on travaille avec le Framework ABCD” et qui pondra bêtement la totalité de ses logiciels avec le même, quitte à ce que le choix soit le bon une fois sur cinq.

Mais qu’est-ce que je constate du point de vue de l’expérience utilisateur ? Ca rame.

La puissance de calcul a violemment augmenté depuis plusieurs décennies, et nous avons dans nos poches des smartphones aussi performants que nos PC de bureaux.

Et pourtant, ça rame.

On a des CPU à trouze mille Gigahertz, des SSD à mémoire flash avec des taux de lecture et écriture qui faisaient rêver il y a dix ans, un débit réseau qui était de la science fiction il y a 15 ans.

Et pourtant, ça rame.

Le moindre site web est devenu tellement lourd et complexe que le visiteur passe son temps à voir une roulette tourner pour montrer un chargement de données ou d’informations. Quand on arrivait sur une page web auparavant, le navigateur téléchargeait un ensemble de fichiers textes et interprétait les instructions pour dessiner la page, c’était quasi immédiat. Aujourd’hui, le navigateur va télécharger des tonnes de scripts et ces scripts vont ensuite refaire le même travail de construction de l’interface et du contenu.

Je ne dis pas, il existe d’excellents logiciels conçus avec de la technologie Web (Diagram.net notamment) et qui ont réussi à masquer la lourdeur de la pile logicielle qui est nécessaire pour les faire fonctionner. Mais ce sont hélas de rares exceptions. J’ai des clients qui utilisent la suite Google Workspace, et je ne constate qu’une seule chose avec elle : c’est lourd et lent. Un onglet Gmail, c’est 800 Mo de RAM utilisé à lui tout seul, Google Doc, c’est lent et pas réactif, Google Sheet, pareil. Oui, ce sont des logiciels bardés de fonctionnalités et qui de ce point de vue n’ont plus à rougir de leurs homologues Desktop (ou aussi appelés “clients lourds”, une appellation bien ironique tant les “clients légers” sont devenus lourds…), mais manquent-ils d’optimisation ou bien sont ils basés sur une technologie qui montre ses limites ? Si je me réfère à la suite Google et à mon client “lourd” Evolution, lui il ne prend que 150 Mo de ma RAM et il est réactif.

Et quand c’est pas le front qui rame, c’est le back. Un autre exemple constaté dans une application métier utilisant beaucoup d’API pour interroger les différents systèmes maîtres (au moins, cette appli connaît sa place dans le SI, c’est déjà ça). Interroger une fiche produit, c’est bien. Cela dit, demander en API d’extraire la totalité de l’historique des mouvements de stock de celui-ci, c’est pas très malin car derrière ça génère plusieurs dizaines de mega-octets de données avec les timeout qui vont avec (quand le backend n’abdique pas, tout simplement).

Tous ces petits soucis et irritants que je rencontre régulièrement dans l’IT m’interrogent. Y a-t-il vraiment un gain à tout développer en technologie Web quitte à avoir 15 instances d’un navigateur Web installées sur son PC (oui, je parle bien d’Electron). Est-ce que la puissance que nos PC et smartphones proposent est vraiment bien exploitée ou bien est-elle gaspillée “parce qu’il y a de a RAM donc faut l’utiliser” ? Les sites Web ont-ils vraiment besoin d’être des logiciels aussi complexes pour répondre à des besoins simples ? Les logiciels sont-ils conçus au service du métier ou bien sommes-nous toujours dans une irréconciliable dichotomie du métier contre la technique (alors que les deux sont censés travailler ensemble…) ?

Les méthodologies Agile et la démarche DevOps nous enseignent qu’il faut régulièrement se remettre en question pour sans cesse s’améliorer. Quand je vois l’état du Web et des travaux que je croise à titre professionnel, j’ai de sérieux doutes que cette pratique soit monnaie courante.

Cela dit, pour conclure sur une note tout de même positive, je constate que le minimaliste et la simplicité semble revenir de plus en plus sur la toile. Peut être que les vieux principes has-been du Keep It Simple, Stupid reviendront en force. Par contre, du point de vue des développements que je vois passer dans le domaine professionnel… Il y a encore du chemin.