Du consommateur au producteur

Openweb.eu.org > Articles  > Du consommateur au producteur

Abstract

Le choix entre « une solution toute faite vite trouvée vite installée » et « une solution développée à la main » n’est vraiment pas simple : approches différentes, espaces-temps différents, coûts différents, etc. L’arbitrage entre ces deux espaces-temps est même souvent un casse-tête redoutable pour les décideurs.

Gaël Poupard se penche pour vous sur cette question très loin d’être manichéenne.

Article

Sur le web, on trouve tout. « Google est ton ami », comme disent les anciens. Mais si vous travaillez « dans » le web, ces trouvailles ont un rôle décisif dans votre production.

Partons d’un postulat simple : nous sommes confrontés à une problématique particulière — elles le sont toutes. Si nous n’avons pas l’expérience de cette problématique, que faisons-nous ? Nous cherchons sur le web. Car il est fort probable que le problème rencontré ait déjà été résolu de diverses manières, dont il existera une trace sur le web.

Et c’est là que notre épopée débute — influencée par des facteurs variés tels que les délais de production, les contraintes existantes, nos habitudes de travail ou notre conscience professionnelle. Projetons-nous à court, moyen et long terme dans deux alternatives de ce récit dont nous serons les héros !

Espace-temps №1

Commençons par le commencement : chercher la solution. Vous vous en doutez, notre recherche retourne des centaines de milliers de résultats.

Soyons pointilleux, et appliquons des filtres de recherches pour affiner ces résultats. Uniquement les résultats récents, sans localisation, et on va préciser un peu notre requête. Fort bien, plus que quelques milliers de réponses.

Un survol rapide de la première page et quelques solutions ressortent déjà. Hop, un nouvel onglet par réponse aguicheuse. On scanne chaque page afin de se faire une idée plus précise des suggestions. Certaines se ressemblent beaucoup et se citent, ce qui permet d’en éliminer quelques-unes. Après une lecture plus approfondie, une bonne moitié ne colle pas tout à fait à notre cas : fermons les onglets concernés.

Parmi les survivants, une solution attire notre attention car elle semble réellement bien répondre à notre demande. Une chance : il s’agit d’un article clair, documenté et illustré. Ça aurait pu être une réponse sur StackOverflow citant W3School ! Relisons une dernière fois l’article pour nous assurer qu’il répond à nos attentes. Parfait !

On se lance ? Remettons-nous sur notre éditeur de code préféré, et appliquons religieusement les conseils prodigués par notre sauveur. On ajoute les scripts et styles proposés, on ajuste les classes et identifiants à notre contexte et… Ça marche !

Le comportement est conforme à nos attentes, c’est cool ! Par contre Internet Explorer 8 fait un truc étrange, mais bon… Ça n’empêche pas le fonctionnement ! Le poids n’est pas terrible pour ce que ça fait, mais une fois minifié et gzippé, qui verra la différence ? Et pour le temps passé, c’est plus que convenable ! Non vraiment, il est appréciable d’être aussi efficient — et le chef de projet se fait une joie de nous le signaler.

Comparé au temps que ça nous aurait pris de le faire from scratch, c’est tout bénéf’ ! Nous avons optimisé notre temps et le Chef de Projet comme le client sont satisfaits. On va pouvoir s’attaquer au cas suivant !

Oui mais…

La mise en production est effectuée sans accroc, le client est aux anges et le Chef de Projet classe l’affaire. Cependant cette façon de faire nous a exposés à divers CNQ [1] :

  • Deux semaines plus tard, le client nous transfère des mails envoyés par quelques internautes, qui incriminent la solution trouvée. Il semblerait que ça ne fonctionne pas dans certains cas rares — et ça ne semble pas simple à corriger ;
  • Un mois plus tard, la nouvelle version de Firefox modifie légèrement sa façon de gérer notre cas et compte bien nous embrouiller tout ça. On ouvre une issue sur GitHub mais elle reste sans réponse, et ça parait compliqué à corriger ;
  • Six mois plus tard, le contributeur chez le client décide de créer une page avec un effet particulier. Manque de chance, le script qu’il a ajouté a complètement bloqué le nôtre… Il va falloir creuser en profondeur pour détricoter tout ça ;
  • Un an plus tard, le client veut obtenir une nouvelle certification pour son activité mais celle-ci exige de répondre au niveau AA du RGAA. Ce n’était pas prévu initialement, mais ce nouveau devis promet d’être salé car notre solution ne permet absolument pas d’y répondre correctement ;
  • Deux ans plus tard, un nouveau projet demande la même astuce. Mince, nos patchs successifs sont encombrants : mieux vaut repartir de la solution originale. Mais où l’avions-nous trouvée ?
  • Trois ans plus tard, suite à une proposition flatteuse, nous avons quitté l’entreprise. Notre remplaçant — bien que tout à fait compétent et plus expérimenté que nous — éprouve des difficultés importantes à traiter une maintenance corrective. Notre solution, patchée déjà quatre fois pour améliorer sa compatibilité et son accessibilité, est incohérente, illisible et coûteuse en performances. Notre successeur décide donc de tout reprendre à sa sauce.

Espace-temps №2

Commençons par un autre commencement : analysons le problème sous toutes les coutures. Quelles sont ses particularités ? À quoi voudrait-on aboutir ? A-t-on des contraintes, des dépendances, des compatibilités, des pré-requis, une liste noire de solutions ? Faudra-t-il pouvoir ré-utiliser la solution ?

Maintenant — et avant de commencer notre recherche — dressons le portrait de la solution parfaite. Idéalement, elle corrige notre problème de façon simple, ne dépend que d’un seul langage, n’implique pas de modification lourde sur notre structure et l’existant, et — autant que faire se peut — elle est légère et accessible. Ça semble réalisable, mais allons voir un peu ce que le web va nous proposer.

Bon… Les premiers résultats semblent partir dans tous les sens, on va préciser notre requête : langage visé, terme « accessible », et on va la lancer deux fois en ciblant respectivement le français et l’anglais. Voilà ! Beaucoup moins de résultats, et on évite les W3School et consorts. Maintenant, de façon arbitraire parce qu’il faut bien avancer, nous allons ouvrir tous les résultats en première page des résultats pour nos deux recherches — et nous allons tout lire !

Non content de lire en détail ces résultats, il va s’agir de les cartographier à la façon d’une carte heuristique — et ce dans le but de réunir les concepts clés des solutions évoquées. Nous allons ainsi recenser les différentes pistes et détailler leurs avantages comme leurs inconvénients. Certaines d’entre elles pourraient même se compléter, allez savoir !

Et en effet, de nombreux points communs apparaissent, et chaque résultat contribue à sa façon. Il est temps de mettre les mains dans le cambouis !

On ne va pas travailler « À La Rache® » alors commençons par créer un fichier dédié, dans le langage désiré. On l’ajoute à notre projet comme il se doit, et BIM ! On peut commencer à coder ! On commence par structurer notre fichier proprement — comme à notre habitude, puis on ajoute petit à petit le fonctionnement qui a émergé de nos recherches en respectant nos conventions d’écritures. Et, évidemment, on commente en détail chaque portion de code en citant nos sources.

Premier test. Ha, non, il doit manquer un morceau… Re-lisons notre code, parcourons nos notes et survolons à nouveau les articles trouvés lors de nos recherches. Ha mais oui, sommes-nous bêtes !? Ces deux portions sont conflictuelles, il faut les mettre en place différemment. Et maintenant ? Eh oui, ça fonctionne !

Bon, très bien. Avançons : qu’en est-il des autres navigateurs ? Firefox : OK. IE11 : OK. Safari : OK. IE8 : OK. Pour une première mouture, c’est plutôt bien ! Maintenant comparons notre nouveau fichier à notre solution idéale évoquée au début de ce récit. Moui, pas trop mal… On pourrait peut-être améliorer ces deux points là, tout de même. Essayons. On se rencarde à nouveau sur notre moteur de recherche favori afin d’en apprendre plus sur ces propriétés. Oui, effectivement : on peut améliorer ça ! C’est parti, un peu d’ingéniosité parsemée ça et là et le résultat est déjà bien meilleur.

Approfondissons nos tests : tous les navigateurs, les différentes tailles d’écran à supporter, le JavaScript désactivé, le CSS désactivé, sans image, en mode de contraste élevé… Parfait, ça fonctionne dans tous les cas de test ! On termine de documenter ce fichier en précisant les configurations testées, la date et quelques informations de contact supplémentaires, et voilà !

Accessoirement, cette solution en regroupe plusieurs et semble à la fois plus simple et plus efficace. Ça vaut le coup de la partager ! On l’ajoute à nos autres répertoires GitHub puis, après les avoir cités dans la présentation de la solution, nous allons notifier les auteurs des solutions qui nous ont aidés.

On y a certes passé plus de temps que si nous avions simplement appliqué une des solutions trouvées, mais cette simple étape de partage et le sentiment du devoir accompli suffit à nous rasséréner.

Mais alors…

Ça n’est pas pour autant une solution merveilleuse, car nous avons traversé quelques COQ [2]. Sa mise en place nous a effectivement pris la journée alors que nous aurions pu traiter le sujet en deux heures. Le chef de projet commence à grogner, mais nous avons finalement pu le convaincre du bien fondé de notre démarche.

D’ailleurs, nous devrions nous estimer heureux : si les solutions découvertes et les technologies sur lesquelles elles reposent avaient été ne serait-ce qu’un tantinet trop loin de notre périmètre d’expérience, il nous aurait fallu bien plus de temps pour monter en compétences et devenir capables de finaliser une solution correcte.

De même si le portrait de notre solution idéale avait été trop ambitieux, nous aurions facilement gaspillé un temps précieux à poursuivre le vent. Et peut-être était-ce le cas, comment savoir ?

Ce sont des pièges difficiles à éviter lorsqu’on se sent en confiance et à l’aise dans notre travail.

Conclusion

Ce sujet est avant tout une façon de concevoir son travail : un investissement à long terme pendant lequel on s’améliore continuellement (Kaizen), ou un enchainement de questions/réponses. Chacun définit sa position favorite devant ce choix, mais il va de soi que rien n’est absolu et des entorses seront parfois à envisager.

Qu’on s’entende bien : parfois vous n’aurez pas le choix. Modification en production « à chaud », grosse faille de sécurité à patcher et que sais-je encore — ou alors ordre express de développer de bout en bout une solution en interne. C’est normal, nous y sommes tous confrontés.

En revanche si vous choisissez systématiquement l’une ou l’autre approche, il est plus que probable que vous fassiez des erreurs de temps à autre : surqualité systématique en cas de recherche permanente, dette technique exponentielle en cas de résolution passive perpétuelle.

Les cas intermédiaires existent, et il est possible — voire même souhaitable — de définir des limites selon votre contexte professionnel. Dans une agence de petite taille, la capitalisation sur de la R&D ne peut pas se faire en continu car le travail se fait souvent à flux tendu. À l’opposé, dans une structure de plus grande envergure et avec moins de cinq projets par an, il serait presque stupide de simplement appliquer un résultat trouvé sur le web.

Notes

[1Si le mot « CNQ » ne vous parle pas, vous pouvez lire « Le coût de la non-qualité sur le Web ».

[2Si le mot « COQ » ne vous parle pas non plus, vous pouvez lire « CNQ et COQ sur le Web : qui va gagner ? ».

À propos de cet article

  • Openweb.eu.org
  • This article also exists in English: From consumer to producer
  • Profil : Débutant, Décideur, Expert
  • Thème : Industrialisation, Méthodes, Qualité
  • Auteur :
  • Publié le :
  • Mise à jour : 22 août 2014
  • 2 commentaires

Vos commentaires

  • Sylvain Le 8 novembre 2014 à 17:40

    Quelque soit la solution retenue, effectuer des tests dès le départ n’est jamais une perte de temps sur le long terme. En effet, dans la première situation, les différents bugs auraient peut-être pu être détectés au départ. Car dans cet exemple on utilise un script vite fait, mais mal ficelé pour la situation. Ce script nécessitera des patchs, souvent faits, à l’arrache aussi, bref, un travail assez vite fait, mal fait, qui n’est pas très satisfaisant intellectuellement et qu’il faudra de toute façon reprendre, car mal conçut à la base.
    Dans la deuxième approche, quelques tests sont réalisés, mais ils pourrait y en avoir d’autres aussi, un peut plus poussés et qui permettraient de partir sur des bases solides.
    Malheureusement dans la réalité, les tests sont souvent négligés car dans la plus part des entreprises, beaucoup de choses sont fait à la hâte, dans l’urgence, pour répondre à des situations qui ne peuvent pas attendre et les tests sont bien souvent tout simplement ignorer, car sans test, pas de problème, du moins au début.
    Cependant, ignorer les tests, c’est s’exposer par la suite à des bugs, des retours négatifs, des clients mécontents... Si on chiffrait réellement les désavantages et désagréments que peuvent causés un projet mal préparés, on se rendrait compte que les coûts sont bien supérieurs à celui d’un développement propre, testé, réfléchit dès le départ.

  • muc in ma vach Le 1er février à 08:26

    En revanche si vous choisissez systématiquement l’une ou l’autre approche, il est plus que probable que vous fassiez des erreurs de temps à autre : surqualité systématique en cas de recherche permanente, dette technique exponentielle en cas de résolution passive perpétuelle.

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici
  • Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom