Les bonnes pratiques pour conduire au mieux un projet web de A à Z

Technique, User Experience

2 juil, 2019

Qui n’a pas en tête l’image du développeur geek barbu qui développe dans son garage à n’importe quelle heure du jour et de la nuit sur un simple éditeur de texte ? Il tape des choses bizarres, incompréhensibles, une série de chiffres et de lettres (te le teuteu teuleu te te teuteu) avec des caractères spéciaux, puis vous appelle en disant « c’est bon c’est en ligne ». Mais qui est ce magicien qui n’a pourtant pas fait Poudlard ? Une machine, un clavier, un écran, un soda et des beignets (sans gluten), et hop le tour est joué il pirate la NSA… No… WAIT!

5 Les bonnes pratiques pour conduire au mieux un projet web de A à Z

Oui elle n’est pas barbue, mais il y a beaucoup de développeuses aussi, ne les oublions pas.

Même si l’image est parfois véhiculée par des séries américaines (oui car les séries françaises ne sont pas terribles, enfin pas toutes mais ce n’est pas le sujet de cet article), tout cela n’est qu’image d’Epinal (on devrait pas dire des pinaux ?)*. Ne soyez pas déçus, ça peut exister, ça doit même encore exister… mais fort heureusement aujourd’hui, du moins dans le monde professionnel, tout tend depuis de nombreuses années à se structurer en mettant en place les meilleurs outils et bonnes pratiques pour conduire au mieux un projet de A à Z.

*désolés pour ça, nous ne voulions pas censurer le rédacteur.

Une idée, un besoin, un projet

La première chose pour bien développer c’est de savoir ce qu’on doit faire. Mais pourquoi nous parlent-ils de banalités, c’est évident ! Évident, évident… disons que ça va mieux en l’disant. Tout part d’une idée, parfois farfelue, parfois répondant à un besoin précis. Dans tous les cas, savoir vers quoi on veut aller est nécessaire pour bien délimiter le périmètre du projet, ce que l’application doit faire et à quel(s) besoin(s) elle doit répondre. En général, ça commence avec un cahier des charges qui permet ensuite de rédiger les spécifications fonctionnelles détaillées (les règles de l’application décrites de la manière la plus exhaustive possible afin de pouvoir tester au fur et à mesure et à la fin du projet le bon fonctionnement de l’application). Les SFDs (Spécifications Fonctionnelles Détaillées) servent de fil conducteur au développement du projet, on sait où on va et ce que fait/doit faire en détail l’application. Sans elles, on perd beaucoup de temps, car on navigue à vue, et ça ne marche pas très bien. On a parfois l’impression de perdre du temps au début du projet, mais ce temps est largement gagné ensuite durant la phase de développement.

Un IDE

L’IDE pour Integrated Development Environment ou EDI en français (Environnement de Développement Intégré) est le premier outil nécessaire (ou du moins qui facilite pas mal la vie) des développeurs. Adapté au langage utilisé pour le développement de l’application (PHP, Java, NodeJS, …), il aide le développeur à se prémunir des erreurs de syntaxe les plus basiques, lui fournit via des auto complétions l’ensemble des méthodes / fonctions utilisables, pré-remplit certains éléments (fermeture de parenthèses, d’accolade, indentation du code, etc.). Plusieurs IDE existent sur le marché, certains open source comme Eclipse, d’autres sous licence, comme PHPStorm ou IntelliJ par exemple. Notez qu’on peut très bien développer avec un simple éditeur de texte… pour les plus téméraires.

De multiples environnements

Contrairement à notre planète bleue que nous aimons tous, il existe plusieurs environnements dans le cadre d’un projet. Certains sont indispensables comme l’environnement de production (sinon ben… le site ou application n’est pas utilisable), d’autres sont facultatifs dans les faits mais carrément plus que nécessaires (fuyez ceux qui prétendent le contraire).

Etat des lieux :

Environnement de développement

Il permet de développer l’application en local sur sa machine (le site n’est alors accessible que sur cette machine). Cet environnement est directement accessible et mis à jour à chaque modification du code via l’IDE comme vu plus haut. Une fois le développement de la fonctionnalité terminé et testé par le développeur, il peut doit « partager » son travail au reste de l’équipe via l’outil de gestion de versions (on en parle plus tard), ce qui permettra également de procéder aux livraisons sur chaque environnement pour recette interne et recette client et enfin pour la livraison finale en production.

Plusieurs outils permettent de simuler les environnements finaux (les serveurs de productions) sur les machines des développeurs, on peut citer par exemple Docker dont nous avons déjà parlé précédemment.

2 Les bonnes pratiques pour conduire au mieux un projet web de A à ZProjet en développement, en local

Environnement de recette / intégration continue

Lorsque le développeur a terminé et testé la fonctionnalité sur laquelle il a travaillé, il partage ce travail via l’outil de gestion de version. Dès lors cette fonctionnalité peut être livrée sur l’environnement de recette (interne) ou d’intégration continue (livraison automatique à chaque fois qu’un développeur « pousse » une nouvelle fonctionnalité). L’environnement de recette est donc l’environnement « en ligne » le plus à jour (mais souvent seulement accessible en interne). Pour ceux qui sont intéressés par l’intégration continue, vous pouvez consulter un de nos précédents articles.

1 Les bonnes pratiques pour conduire au mieux un projet web de A à ZUn travail d’équipe, mais qui est loin d’être terminé

Environnement de pré-production

On commence à entrer dans le vif du sujet… Une pré-production, comme son nom l’indique, est l’environnement juste avant la production. Il sert surtout à livrer une version du site, qui contient un ensemble de fonctionnalités, et chacune d’entre elles devront être testées et validées, ainsi que le bon fonctionnement de l’ensemble du site (pour éviter toute régression). Une fois la pré-production validée, cet ensemble de fonctionnalités est alors livré en production, on parle de release ou de version (majeure ou mineure en fonction de l’importance des changements apportés).

Notez qu’il est primordial que cet environnement de pré-production soit iso (similaire) en tout point à celui de production (même version du langage, des plugins, outils, mémoire, etc…).

4 Les bonnes pratiques pour conduire au mieux un projet web de A à ZLe projet est terminé, prêt à être testé avant la mise en production finale

Environnement de production

C’est le dernier des environnements, celui qui sert à tous les utilisateurs de l’application. Quand il y a un problème sur cet environnement là, en général, c’est pas bon… le fameux bug en prod, c’est ALERTEEEE GENERAAAAAAALE comme dirait le charismatique commandant Gilbert de Marseille.

Ah oui, au fait. Il est INTERDIT de livrer en production un vendredi ou une veille de jour férié. On a beau mettre en place toutes les mesures qu’on peut, on ne joue pas avec le feu. JAMAIS. C’est d’ailleurs désormais interdit par la Convention de Genève sur les Développements Informatiques (la fameuse CGDI*) et passible de lourdes peines. Non, vraiment, on ne livre pas un vendredi. D’ailleurs, vous pouvez vérifier cette information ici -> www.estcequonmetenprodaujourdhui.info

Un système de livraison

Un système de livraison permet d’assurer la livraison du code source sur un environnement cible. Non on ne livre plus fichier par fichier… Car c’est assez fastidieux, source d’erreur, pas du tout sécurisant pour la version de l’application, non vraiment… nous avons des outils qui permettent de livrer automatiquement une version donnée, on les utilise. Posez-vous la question : si vous deviez vous faire livrer une boîte de LEGO (non cet article n’est pas sponsorisé), vous trouverez plus sûr de recevoir une boîte qui contient l’ensemble des pièces nécessaires pour réaliser le Millennium Falcon de Star Wars (exemple totalement pris au hasard) plutôt que recevoir pièce par pièce en vrac, non ? Ben c’est pareil.

3 Les bonnes pratiques pour conduire au mieux un projet web de A à ZNon, La Poste ne livre pas les projets

Un outil de suivi

Un outil de suivi permet de savoir où en est le projet. Chaque fonctionnalité est listée, on sait qui s’en occupe, à combien de pourcentage d’avancement on en est, sur quel environnement il est livré… bref c’est indispensable pour assurer un bon suivi et un bon déroulement du projet. On peut citer Redmine comme outil reconnu. L’outil permet également de remonter les anomalies, bugs et demandes d’évolution. La classe.

Un outil de gestion de versions

On en a parlé dans les parties précédentes. L’outil de gestion de versions permet de sauvegarder le code et de le versionner tout au long de la vie de l’application. Ainsi le code source est accessible par tous les membres du projet, on peut revenir à des versions précédentes (en cas de régression), et regrouper par lot des fonctionnalités (et par exemple avoir la version 1 en prod, la version 1.1 en préproduction, la version 1.2 en recette, etc…). Carrément INDISPENSABLE comme outil. Le plus célèbre aujourd’hui est GIT, mais il y a aussi SVN et CVS.

6 Les bonnes pratiques pour conduire au mieux un projet web de A à ZLa vie de dév’ ne se déroule pas toujours du côté de chez Swann.

Nous avons essayé de faire le tour de la question, bien qu’on ait survolé par de grandes généralités (pour certains points nous vous invitons à consulter les articles dédiés) ce vaste sujet qu’est la mise en production d’un site ou d’une application. Bien évidemment, chaque projet possède son propre contexte et ses propres contraintes, et tous les outils existants doivent être adaptés à chaque situation, mais l’idée générale de structurer chaque pan de la vie d’un projet, de la naissance de l’idée à sa mise en ligne, en passant par sa conception et son développement, est très importante pour s’assurer que tout se passe au mieux. Et finalement, c’est ce qui compte. Alea Jacta Est, merci, bonsoir.

 

* Non, la CGDI n’existe pas. Désolés. Mais on ne livre pas un vendredi.

 

Laisser un commentaire.