Pour commencer l’année sur de bonnes bases, je me suis décidé à mettre un peu d’ordre dans mes projets. Je le fais via Github pour à la fois vous les présenter, mais dans le but également de versionner les projets qui y sont déposés et de les améliorer dans le futur.
Mes différents projets aujourd’hui
Aujourd’hui, j’amasse pas mal d’outils et de projets fait maison, et je me dois d’en indexer le résultat. Comme vous l’avez peut-être remarqué, je termine toujours mes projets web par « in » et j’associe également les images de mes articles à des concepts clé (cachés) dans le but de les mémoriser et de retrouver tout de suite ce dont il s’agit. C’était surtout pour agrémenter le projet en cours et c’est toujours très chouette de donner un nom à sa création. (Comme d’inventer le nom d’un groupe de rock par exemple ! ). Mais avec le temps, je me suis retrouvé avec une quantité de projets sous le bras, tous n’étant pas versionnés, et il fallait faire le point. Il me paraissait alors important de « cartographier » ce qui a été codé, afin de voir ce sur quoi se concentrer ou simplement validé ce qui est terminé dans une version « convenable« . Je me suis dans le même temps penché sur ma méthode de travail, et je pensais utile de vous en faire part en ce début d’année.
Indexation & méthode de travail
Tout d’abord, j’ai pensé réalisé un index de mes projets versionné sur Github. Et pourquoi d’ailleurs ne pas le faire via le fichier readme.md par défaut lorsque vous vous inscrivez sur la célèbre plateforme ? C’est ce que j’ai fait ! Si vous ne connaissez pas Markdown, sachez qu’il s’agit d’un petit langage léger et surtout lisible pour tout un chacun lorsque vous y êtes confrontés. Il est ensuite très facile de convertir le langage dans d’autres formats ou même de le convertir en fichier PDF par exemple. En d’autres termes, il relie le document texte « basique », au développeur. Sur Github, chaque dépôt (projet) à un fichier Markdown afin d’en donner une explication. Pour avoir une idée de à quoi cela ressemble, vous pouvez utiliser cet outil en ligne : https://markdownlivepreview.com/
Et la méthode ?
Pour l’instant, je garde toujours ma méthode des « 5 piliers » dont je vous avais fait part il y a plus de 3 ans maintenant. En gros, je sépare un projet web en 5 grands segments que sont : « Le contenu« , « Le frontend (ou le style) », le « Backend (ou le dev) », le « SEO » et la « Sécurité« . Évidement, ces segments sont très liés et s’entrechoquent. Mais globalement, cela me permet de ne rien oublier. Je sais que cette séparation n’est pas parfaite. En effet, je ne parle pas dans cette méthode de la performance ni de l’analyse après la mise en ligne (fréquentation, tags et services externes…). J’ai pris l’habitude de placer tout cela dans la partie « SEO« , tout comme l’accessibilité. D’ailleurs, un site web qui est trop lent ou qui ne respecte pas les règles d’accessibilité (pour les personnes handicapées), est pénalisé au niveau du SEO, …
Processus
En général, lorsque j’ai le contenu que le client décide de communiquer, je transforme ce dernier en sections propres au web. C’est-à-dire facile à lire sur téléphone, mais aussi sur tablette et sur écran. Autrement dit, je fais ce qu’on appelle aujourd’hui de l’expérience utilisateur. Je transforme le contenu pour qu’il soit le plus facilement manipulable et clair sur les différents supports de communication par lesquels il sera lu. (il s’agit d’un tout autre métier, au boulot, ce n’est pas moi qui m’en charge !).
Pour vous donner des exemples concrets, imaginons un texte très long, qui serait utile de transformer sous forme de questions-réponses et d’en faire une FAQ, dont les réponses sont rétractables et donc plus claires pour un utilisateur qui sait ce qu’il recherche ou noyé par un texte trop long à lire. Ou à l’inverse, un paragraphe trop court, est sans doute plus lisible accompagné d’une image, afin de donner un contexte au contenu et de renforcer dans le même temps le SEO … Toutes ces méthodes sont connues de la culture web et me permettent de donner forme à une maquette (le wireframe) que je « dessine » à la main avant de décider au final du contenu final de chaque section. Chacune de ces sections composera ensuite vos différentes pages qui au final, réaliseront votre site web. (méthode modulaire)
Pour conclure, je travaille au final comme tout le monde :
- Rassemblement du matériel graphique et textuel qui identifiera le contenu de mon site
- Réflexion et création des wireframes ; le plan du site, son arborescence et comment l’utilisateur va naviguer à travers lui (ux)
- Design du contenu, compatibilité et approbation du style via un aperçu comme Figma par exemple
- Codage du style
- Intégration du contenu via le code, en tenant compte du SEO (balises) et de l’accessibilité.
Aussi des langues, s’il y en a plusieurs. - Partie DEV si le site n’est pas statique. (formulaires, base de données, e-commerce, CMS etc…)
- Testing & débeug : on teste les formulaires et tout le cheminement de l’utilisateur
- SEO & optimisation : balises og, compression des images, ajout des titre & description des pages
- Sécurité : sauvegarde, mise en place d’un certificat SSL une fois en ligne et d’un pare-feu
- Mise en ligne en respectant les aspects techniques : hébergement, noms de domaines
Et le reste ?
Comme dit précédemment, chacune de ces catégories sont très liées, et il serait faux de se consacrer au SEO et à la sécurité avant la mise en ligne finale. C’est un travail à réaliser tout au long de la création. Cependant, il est clair que je configurerai le fichier sitemap.xml, robots.txt ou encore le fichier .htaccess (sur Apache) en fin de processus, pour des raisons évidentes (…). Enfin, je suis adeptes du texte de substitution (vous vous rappelez ?) ou même des images de substitutions dans le cas où mon prestataire ne me donnerait pas tout le contenu à implémenter. Cependant, il est toujours préférable d’avoir tout le matériel au préalable. Ne fus que pour avoir une idée de la place que cela prend au niveau du design, mais aussi de la quantité totale à coder. Enfin, je ne vous ai pas parlé de la rédaction d’un cahier des charges à faire en début de processus ou encore de la maintenance, des backups et des mises à jour à réaliser au quotidien. Mais pour moi, il s’agit d’autres étapes que je qualifierai d’externe au travail réel du développement pur du projet mis en route.
Et vous, quelle est votre méthode ?
Newsletter
En maintenance ...