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