Il y a quelques jours, je me réveillais un matin avec une notification de **Bankin** qui avait généré mon relevé. Curieux je me dis bon, je jette un oeil, et après quelques slides je vois une transaction mensuelle d'environ **40€** pour **AWS**. Le chiffre dans l'absolu n'est pas fou, mais si je vous dis que c'est pour un service qui est appelé à tout cassé 10 fois dans le mois, là c'est tout de suite overkill.

### Les frais chez AWS

Dernièrement je parlais de [comment je choisis d'héberger mes solutions](https://dev-freelance.fr/dev/passer-de-frontend-a-backend-le-deploiement) et je vous disais que j'optais souvent pour des **VPS** grâce à leur faible coût. Non pas que je trouve qu'**AWS** soit trop cher, mais trop cher pour ce que je fais. **En effet, tout dépend de votre objectif !**

#### L'envergure du projet

Lorsque vous avez un projet de taille moyenne voire plus, c'est à dire qu'il vous faut au moins une équipe et plusieurs mois avant de sortir quelque chose, bien sûr qu'une solution **AWS** de type **serverless** est justifié, car tout ce temps passé à ne pas gérer le déploiement vous permet de vous concentrer sur les développements et les fonctionnalités. En revanche lorsqu'il s'agit d'un petit projet, avec peu de requêtes entrantes, je vous conseille de réfléchir à deux fois.

Pour ma part j'avais opté pour **AWS Serverless** (**Lambda** + **API Gateway**) et **RDS Postgres** pour un projet mobile que j'utilisais de temps en temps avec des amis. Mais à ne pas regardé cela fait plus de 2 ans que je paye cette solution et que plus de 1000€ ont été débité en tout pour faire tourner une base de données et un processus d'**API Node**.

#### Combien j'aurais économisé si j'avais tout fait moi même ?

Et bien c'est assez incroyable, mais j'arrive à **compresser les frais de 8 à 10 fois** pour ce genre de petit projet. Cela signifie que sur une plage de temps similaire, j'aurais dépensé en tout **100€** et des brouettes, au lieu des **1000€**. Ce qu'il faut garder en tête, c'est souvent, combien de temps va durer ce projet, et si c'est du long terme, je vous conseille d'optimiser vos frais avant tout !

J'opterais donc pour une solution **Scaleway** ou **PulseHeberg** **VPS** pour héberger des petits projets personnels. D'ailleurs en ce moment même je suis sur la refacto de cette application.

### Conclusion

Lorsque vous faîtes des projets personnels, des prototypes, etc. pensez d'avance aux frais que ceux-là vont générer dans la durée. Et ne négligez pas les optimisations que vous pourrez faire d'avance. Optez pour des solutions managées dans le cas d'application live avec de grosses audiences sur des projets longs. 💸💸


towfiqu-barbhuiya-xkArbdUcUeE-unsplash.jpg

large_towfiqu-barbhuiya-xkArbdUcUeE-unsplash.jpg

medium_towfiqu-barbhuiya-xkArbdUcUeE-unsplash.jpg

small_towfiqu-barbhuiya-xkArbdUcUeE-unsplash.jpg

thumbnail_towfiqu-barbhuiya-xkArbdUcUeE-unsplash.jpg

AWS me facture une blinde chaque mois depuis des années pour un service que j'utilise à peine. Je décide d'optimiser ça.

Je lache AWS

## Les étapes de lancement de produit tech

On nous parle souvent des boîtes qui ont coulé, ou qui ont échoué etc... Pour chaque société autrefois leader de son marché qui a disparu par la suite, combien sont passées complètement inaperçues, car morte avant même d'arriver au marché ?

Lancer un produit sur une base applicative n'est pas de tout repos. 

Admettons que l'on ait fini ce que j'appelle le **pré-pré-lancement** : 
- avoir la vision du produit
- avoir monté l'équipe
- choisi les technologies
- avoir en tête les principaux use-cases
- connaitre sa cible

Il y a ensuite les phases : 
- de **pré-lancement** (on souhaite accélérer la sortie du produit) 
- d'**après-lancement** ou **post-lancement** (on ajuste au mieux le produit pour améliorer les rendements, on fait de l'acquisition d'utilisateurs)

La phase de **pré-lancement,** c'est à dire que l'**on a toujours pas de produit**, **ni de market-fit** est composée de 3 étapes (en tout cas aux yeux d'un développeur) : 
- **les premières briques** (la phase d'accélération)
- **le peaufinage** (la phase de stagnation)
- **le early-stage** (la phase de refacto/pivot)

![product-pre-launch-steps ><](https://bo.dev-freelance.fr/uploads/timeline_drawio_27ada4a6fb.png)

Si vous avez déjà fait plusieurs lancement de produits, vous connaissez ces étapes et si vous êtes actuellement en train de lancer votre produit, vous avez plus où moins une idée d'où vous vous positionnez en ce moment, sur cette frise.

En sachant que dans le temps, chacune de ces étapes sera de plus en plus complexe pour votre équipe. Cela signifie qu'**à chaque fois, les problématiques rencontrées seront plus compliqués à résoudre et c'est ici que vous allez vous expertiser dans votre marché**.

Puis, à chaque étape, vous êtes en train de mettre une barrière à l'entrée plus élevée pour la concurrence. 

J'ai plusieurs fois traversé ces phases sur de nombreux projets, où nous n'avons pas passé le pré-lancement. Je vous donne aujourd'hui 9 clés tirés des projets sur lesquels j'ai travaillé, qui sont allé jusqu'au lancement, car j'ai pu comparer en quoi nous avons agit différemment et les problèmes que nous avons résolus.

### I - La phase d'accélération

En général cette phase dure 3 à 6 mois et c'est dans cette phase que votre équipe technique prend le plus de plaisir à évoluer, car : 
- les résultats arrivent rapidement (la première API, les premiers écrans)
- beaucoup de choses sont faites
- tout semble aller vite

En revanche, il convient de faire des mouvements et des choix stratégiques ici pour ne pas se coincer dans les étapes à venir.

#### 1 - Le choix des bons outils techniques ✔️

Si dès cette étape vous faite le mauvais choix de langage de framework etc., vous risquez d'avoir à faire des changements plus tard et ceux-ci peuvent s'avérer très coûteux. 

C'est pourquoi, ici, il faut être sûr de faire les bons choix et d'avoir les bons interlocuteurs techniques (des leads expérimentés) pour ne pas se tromper de voie.

**Un de techno switch tardif pour certaines société peut coûter plusieurs millions.**

#### 2 - S'entourer d'experts 🤝

Oui, vos équipes sont déjà constituées, cependant il existe des profils encore plus expérimentés qui, certes, ne resterons pas dans votre entreprise sur la durée mais peuvent faire monter en compétence vos équipes internes ou vous aider à débloquer une problématique complexe.

S'entourer d'expert (des intervenants par exemple) est vital pour vous aider à prendre les décisions stratégiques pour le long-terme.

Bien sûr, le but n'est pas de faire de l'over-engineering. Cependant, faire le mauvais choix à une étape cruciale de votre développement peut littéralement tuer votre produit. 

**Un expert n'est pas forcément technique, il peut aussi vous conseiller en stratégie, vous conseiller en marketing, être un product-owner, ou encore designer etc...**

>Imaginez-vous, en 2015, Deezer avait 51% des part du marché du streaming en France (source: capital.fr). En 2016, ces parts sont passé à 42%. Et en 2021, il reste moins de 30% du marché français pour Deezer et 2% du marché mondial et Spotify rafle plus de 31% du marché mondial (source: bfmtv.com).

On est bien d'accord qu'il y a un virage qui a été très mal négocié pour passer de leader à "presque disparu" d'un marché. Et dans toutes les tragédies des sociétés (je ferai un article prochainement sur ce sujet), **il y a un mauvais choix à l'origine de toute la dégringolade**.

Et personnellement, (peut être que je me trompe), je pense qu'**il y a forcément une personne sur Terre, où qu'elle soit, qui aurait pu vous insuffler la bonne direction, au bon moment**, mais, soit vous ne l'avez pas sollicité, soit vous ne l'écoutiez pas... 

#### 3 - Eviter les régression 🤚

Lorsque vous avancez très vite, sachez qu'il est tout aussi facile de reculer rapidement. Cette règle est universelle, mais dans le cas d'un projet tech, il y a peut être une solution.

Mettre en place des Tests Unitaires (TU) et des tests End to End (E2E) vous permettra d'éviter de faire marche arrière à chaque nouvelle feature.

C'est un outil qui concerne surtout l'organisation en tant que développeur, mais je vous conseille d'adopter des méthodologies TDD au plus tôt pour éviter de devoir le faire plus tard. 

De même, il y a plusieurs choses à prendre en compte : 
- Il est inutile de faire un coverage de plus de 80% (il faut se concentrer sur les key-features et les parcours critiques)
- Chaque fois que l'on aura décider de ne pas faire de tests pour quelque chose d'important, cela nous retombe dessus tôt ou tard
- Etre sûr de maîtriser ses scénarios de tests (avoir tous les cas en tête) car c'est le cas que l'on a pas vu venir qui pose souvent problème

>Régression = Retard !

**L'histoire a montré plus d'une fois, que des marchés se perdent, parce qu'à un moment, une entreprise accumule plus de retard que ses concurrents dans la sortie de son produit.** 

Cela a été le cas pour la sortie des vaccins, **les laboratoires français** ont été submergés par les retards. Cela a été aussi le cas pour **Google+**, car **Google** a trop longtemps délaissé les réseaux sociaux et ne pouvait plus rattraper **Facebook** lorsqu'il a voulu s'y mettre.

### II - La phase de stagnation

Après avoir été productif, place à une phase qui va être difficile à surmonter pour beaucoup d'entreprises. Cette phase où tout semble se ralentir, va amener avec elle plusieurs problèmes.

Chaque jour semble vous éloigner de votre objectif (le marché), le personnel se démotive, car on entre dans une phase répétitive. 

Les tâches de peaufinages consistent à faire des finitions graphiques ou d'architecture. Souvent, il s'agit même à faire du copier/coller de l'existant. Mais pourtant, cela arrive à démotiver les troupes. Parfois même, c'est à ce moment que certaines sociétés subissent un gros turnover.

Je n'ai malheureusement aucune formule miracle pour cette phase, car elle est inévitable. Mais j'ai quelques conseils à vous donner afin d'en tirer profit.

#### 1 - Gardez les plus motivés 🎣

Si vous subissez un turnover, comme cela peut être le cas dans toute les boites. Il faut savoir l'accepter. 

Peut-être que votre projet ne motive pas toutes les personnes de votre équipe autant qu'il vous motive vous, et c'est tout à fait normal. Après tout, on a chacun nos objectifs dans la vie. 

Ceux qui restent se démarqueront par : 
- leur motivation
- leur loyauté 

Vous pourrez leur donner plus de responsabilités à terme et il faut le voir d'un bon oeil, car il est difficile de porter tout le projet sur ses épaules.

Il faut aussi veiller à répartir équitablement la charge dans les équipes afin que personne n'ai l'impression d'en faire plus que les autres. 

De même, **vous êtes peut être en train de constituer le noyau dur de votre équipe**. 

#### 2 - Pousser la veille technique 🔬

Pendant la phase de stagnation, le projet semble évoluer lentement et nous faisons les observations suivantes : 
- il manque encore des fonctionnalités ou de la stabilité pour pouvoir aller au marché
- les dernières tâches semblent être les plus longues 
- souvent le travail est répétitif

Dès que vous sembler buter sur une situation complexe, demandez à vos équipes pour faire de la veille, afin de trouver des solutions innovantes aux problématiques. 

Peut être que la phase la plus difficile à traverser, sera aussi, celle d'une percée sans précédant pour votre entreprise. **Vous allez peut être résoudre un problème qui vous donnera une longueur d'avance sur vos concurrents**.

A cette étape, si vous trouvez quelque chose de très intéressant mais pas vital pour votre prototype, pensez à le noter pour plus tard. 

De même, lorsqu'il sera intéressant d'ajouter une fonctionnalité, il faudra arbitrer entre, sortir plus rapidement ou être prêt à attendre un peu plus mais augmenter la qualité du produit à terme.

#### 3 - Concevoir ses propres outils ⚒️

J'ai toujours poussé les équipes à avoir des outils adaptés aux problématiques quitte à les concevoir eux même. 

Je le dis souvent : **Vous imaginez vous enfoncer des clous à la main, aujourd'hui ?**

Un outil adapté c'est un gain de temps précieux car **l'ennemi numéro 1 de la société en phase de lancement, c'est le temps !** (Si pour vous, c'est l'argent, lancer plus vite vous fera résoudre ce problème).

>Lorsque vous aviez mis les premières briques de votre projet, combien de temps avez-vous gagné en utilisant un framework ? 

La bonne nouvelle, c'est que vous pouvez reproduire ce schéma pendant la création de votre produit. **A chaque fois que vous faîte quelque chose qui vous semble répétitif, il y a de fortes chances que vous ayez encore à le faire dans le futur. La répétitivité est un excellent indicateur de ce qui peut être automatisé**.

Vous êtes en train de créer un énième path pour votre API ? Vous pouvez l'automatiser.
Vous êtes en train de créer une nouvelle page de gestion de donnée dans votre backoffice ? Vous pouvez l'automatiser.
Vous êtes en train de créer un nouveau modèle de données pour votre DB ? Vous pouvez l'automatiser. 
etc...

Vous allez me demander comment automatiser tout ça ? 

Créez vous des scripts de génération de fichier. 

Il vous faut : 
- Faire des templates
- Créer un CLI (command line interface)

Même si vous gagnez 20%, 30% c'est bon à prendre non ? Alors faîtes-le !

Un autre avantage de l'automatisation, c'est que lorsque vous accueillerez un nouveau dans votre équipe, plutôt que lui faire faire une grosse montée en compétences, les outils d'automatisation vont accélérer sa productivité.

**Je précise tout de même que je parle ici d'outils (automatisation, organisation, etc...). Je ne parle pas d'innovation et de remise en question de tout le process (très important pour la suite).** 

### III - La phase de refacto/pivot

Une fois que vous aurez survécu à la phase de stagnation, il y a un rayon de soleil qui se profile à l'horizon. 

Généralement, vous allez entrer dans une phase où vous allez commencer à faire des ventes. Certes, vous n'allez pas atteindre immédiatement le point d'équilibre dépenses-rentabilité, mais vous allez pouvoir toucher un marché à taille réduite.

Il arrive que des entreprises fassent un lancement à grande échelle dès maintenant, mais cela n'est pas conseillé. En général, vous cherchez une audience réduite pour faire un lancement early stage pour ce que l'on appelle des early-adopters. 

Ces early adopters vous permettent de vous tromper dans vos hypothèses et de pouvoir recommencer. Le problème d'un marché, c'est que lorsque votre offre sera référencée comme étant "mauvaise" (car dysfonctionnelle, ou autre), vous aurez beaucoup plus de mal à convaincre de nouveau. 

Ces prospects que vous aurez atteint plus tôt grâce à votre communication, votre marketing, votre réseau, etc. et qui sont prêt à prendre votre produit. 

Essayez de lancer votre produit à tarif réduit (pour commencer). Je vous déconseille le gratuit même si beaucoup le recommandent, car cela peut être à double tranchant. 

Premièrement, le gratuit peut retirer de la valeur à votre produit, car il sera perçu comme étant facile à donner. Deuxièmement, il faut avouer que le marché francophone n'est pas le meilleur quand il s'agit de payer un produit. 

Les français sont souvent mécontent du prix, de la qualité, etc... bref, ils sont difficiles à convaincre. Notez que dans un pays anglo-saxon, la méthode du gratuit pour commencer peut fonctionner. 

Mais voyons plutôt ce que nous pouvons faire pour tirer profit de cette dernière phase de pré-lancement.

#### 1 - S'appuyer sur ses outils 🏗

Lorsque l'on commence à atteindre un marché, on va commencer à observer ce que l'on peut améliorer, refaire, et même recevoir le feedback de nos utilisateurs. C'est à ce moment précis, que vos outils (II - 3) seront utiles.

**Tout le temps passé, à créer vos propres outils et vos automatisations, vous donnera la capacité de pivoter plus vite.** 

#### 2 - Tirer profit de la veille technique, challenger les solutions 👨‍🔬

Ce que vous avez noté d'intéressant mais que vous avez choisi de le reporter à plus tard (II - 2) doit être fait à ce moment précis.

Pour vous illustrer ceci, je vais vous parler de l'importance d'avoir un produit tech robuste pour le déploiement à grande échelle : 

>Mise en situation : vous êtes la société A en phase de pré-lancement, vous avez créé un prototype très simple, qui n'est pas parfait mais fonctionnel. 
>En phase de refacto/pivot, vous sortez cette solution, qui fonctionne toujours à merveille avec une audience réduite.
>Lors du lancement, votre acquisition explose, mais votre application ne tient pas la charge car jusqu'ici vous fonctionnez qu'avec 100 utilisateurs maximum en parallèle. 

Il faut garder en tête que lorsque votre produit sera déployé à grande échelle, est-ce que vos fondations sont suffisamment solides pour tenir la charge ?

Si votre réponse à cette question c'est : si on a trop de charge on augmente les ressources machines, cela signifie que votre produit n'est pas optimisé et peut-être pas prêt.

Pour vous donner un exemple : 

>On est en 2018 en région parisienne, un confrère lance un projet d'application mobile en temps réel. Pendant toute la phase de tests il est monté à 100 machines en parallèle, et jusque là, ça allait. Lors du lancement réel, la stack ne tenait pas 5000 utilisateurs et pourtant, l'objectif initial était de monter à 100K utilisateurs.

Non seulement, l'échec du lancement a fait quitter les 5000 utilisateurs déçus par une expérience médiocre. De plus, cela mettait en évidence un énorme problème de conception qui impliquait une réimplémentation totale pour arriver à l'objectif. Finalement, cet échec a tué le projet... la boite s'est assise sur son investissement initial. Pire, les utilisateurs ont gardé un gout amer de cette expérience et l'image de la boite était entachée.

**Le problème ici, c'est que le sujet n'était pas suffisamment maîtrisé (manque de veille technique). De même, la conception aurait dû être challengé. La société aurait dû mettre en concurrence plusieurs approches mais ne l'a pas fait.**

Tout ceci me fait me questionner : Etes-vous toujours sûr à 100% du jugement de votre équipe ? 

Cela ne signifie pas remettre en question votre confiance en eux, mais juste accepter que personne ne maîtrise tous les sujets.

#### 3 - Emettre de nouvelles hypothèses 🤔

Lorsque vous êtes dans cette phases, il convient d'ajuster au mieux vos résultats en faisant des hypothèses et en les mettant à l'épreuve.

Si vous avez une conversion de 10 sur 100 prospects, peut-être que vous pouvez tester une nouvelle approche, un nouveau type de campagne publicitaire, un nouveau prix, etc... **Ces ajustements continus vous permettront de maximiser les résultats.** 

De même étant donné que vous avez déjà quelques retours de vos utilisateurs, vous pouvez désormais vous appuyer sur leur avis pour savoir de quoi ils ont besoin. 

Avec tous les outils et l'expérience que vous aurez obtenus des précédentes phases, vous êtes équipé pour répondre encore plus rapidement et encore mieux aux besoins de vos clients.

### Conclusion

De toutes les phases que traverse l'entreprise tech, la plus difficile est bien la phase de pré-lancement. Lorsque vous n'avez toujours pas atteint le marché, vous vous éloignez chaque jour de votre seuil de rentabilité, tout ce que vous faîtes au quotidien, c'est brûler votre cash. C'est pourquoi, je pense que c'est la phase pendant laquelle vous devez faire preuve d'excellence. 

Plus vous irez vite, plus vous réduirez les coûts. De même, il faudra prendre une série de bonnes décisions pour ne pas rencontrer le mur au bout de la piste. 

Le marché est peut-être cruel mais il a toujours raison. Et si des géants comme Google ont pu se planter sur les réseaux sociaux, cela montre qu'aucune société n'est à l'abris d'un mauvais jugement. 

Les solutions à ces problématiques se trouvent dans la maîtrise totale de votre sujet, soit par l'expérience, soit par le conseil d'experts. Mais il n'y a pas meilleur école que l'échec, donc je pense qu'il faut savoir rester détendu face à cela et en sortir grandi. 😁

large_markus-spiske-XrIfY_4cK1w-unsplash.jpg

medium_markus-spiske-XrIfY_4cK1w-unsplash.jpg

small_markus-spiske-XrIfY_4cK1w-unsplash.jpg

thumbnail_markus-spiske-XrIfY_4cK1w-unsplash.jpg

markus-spiske-XrIfY_4cK1w-unsplash.jpg

Une société tech passe en général par plusieurs phases lors de la création de son produit. Avant même d'aller au marché, elle rencontre déjà quelques résistances. 
Une fois que l'on a la vision, choisi les technologies, monté son équipe, que l'on a une idée des workflows (scéniarios d'utilisation) et que l'on connait son avatar client, comment affronter les difficultés pendant notre pré-lancement ? 

9 clés pour survivre à son pré-lancement

## C'est quoi la Webcup Réunion ?

Le concours de la **Webcup** est un hackathon organisé chaque année dans les îles de l'Océan Indien (la Réunion, Maurice, Rodrigues, Mayotte, les Comores et Madagascar) par [l'association Webcup](https://www.webcup.fr/) et a pour but de divertir et faire s'amuser les participants autour d'un projet Web excitant à réaliser dans un temps très court. 

Chaque île concourt d'abord sur son territoire afin de désigner son champion qui affrontera les autres îles ensuite dans une grande **Webcup** inter-îles. 

La **Webcup** et moi, c'est une longue histoire. J'ai été moi-même participant en 2015, j'ai passé un excellent moment. Mon sujet de l'époque, développer le réseau de transport révolutionnaire inter-îles. J'avais codé avec 3 amis (un excellent développeur back, une designeuse et une CM) une plateforme de ticketing en **AngularJS** (premier du nom) avec un backend **PHP**. Nous n'avions pas gagné ce soir là, malgré une seconde place et nous avions surtout beaucoup appris. Je vous en dis plus plus bas...

### Déroulement d'une Webcup

Lorsque vous participez à une **Webcup**, vous arrivez bien assez tôt pour pouvoir vous organiser. Le concours se déroule dans un gymnase équipé pour l'événement. 

Au lancement, vous recevrez les sujets et c'est le top départ pour les équipes qui ont 24 heures pour réaliser ce qui est demandé. 

Petit conseil : il faut vous positionner stratégiquement pour ne pas avoir le soleil dans les yeux le lendemain dès l'aube. 😵 Car non seulement, vous faîtes une nuit blanche de code, mais en plus, vous devez vous préserver physiquement pour être le plus efficace possible, intellectuellement.

![webcup-reunion ><](https://bo.dev-freelance.fr/uploads/taupe_thumb1_c99930bb91.jpg)
Crédit photo : https://www.webcup.fr

Tout au long de la soirée, vous recevrez davantage d'indications sur le concours. Au-delà du thème annoncé à l'ouverture, vous devrez réaliser des étapes bonus pour gratter un maximum de points. 💪

### Ce que la Webcup m'a appris

24 heures, c'est court et ça passe très vite ! Pourtant dit comme ça 24 heures ça parait long... Après tout, on fait des semaines de 35 heures, et 24 heures c'est déjà bien 2/3 d'une semaine de boulot.

Sauf que non. Chaque jour, le rythme de travail dans le boulot est différent car on arrive le matin, rechargé du sommeil de la veille. Lors d'une Webcup, enchaîner 24 heures de programmation, croyez moi, votre cerveau ne réagit plus du tout de la même façon. 

Vous pouvez vous prendre la tête pendant 2 heures pour quelque chose que vous faîte en 15 minutes en temps normal, mais fatigue oblige ! 😴

Donc que faut-il faire ? 

#### Faire des choix 

Il faut faire un maximum de choix radicaux en amont, c'est à dire, **être prêt à abandonner certaines features pour aller directement gagner le maximum de points essentiels**. Après le fait de se positionner stratégiquement, il faut aussi jouer stratégiquement ! 

La Webcup est transparente et les participants savent quels sont les éléments qui rapportent le plus de points. Donc, il faut savoir quand est-ce que c'est raisonnable de tenter la chose, ou pas. C'est pourquoi, il est aussi important de se connaître en tant que développeur. 

Savoir ce que l'on sait faire c'est une chose, mais c'en est une autre de savoir combien de temps cela nous prend pour apprendre une technique. L'apprentissage dans un laps de temps très court, c'est déjà plus difficile. On parle de comprendre, et d'exécuter en moins de 24 heures.

De plus, il faut toujours arbitrer lors des exercices en se demandant : 
- Est-ce que le jeu en vaut la chandelle ?
- Est-ce que je garde ou je retire telle feature à la place ?
- Est-ce que je tente le bonus ou pas ?

#### Planifier au maximum 

Lorsque l'on concourt en équipe, il faut une bonne organisation. Chacun doit être utile et faire avancer les autres, c'est pourquoi il faut répartir les tâches au mieux pour : 

- Ne pas se marcher dessus (faire 2 fois la même chose)
- Ne pas se retrouver dans une position d'attente de l'autre (il faut réussir travailler en parallèle)
- Savoir quoi faire après chaque tâche
- Etre flexible et inverser des rôles à tout moment

Une équipe doit se compléter et chacun doit motiver les autres à ne pas lâcher, car en 24 heures, vous vous demanderez souvent quand est-ce qu'on arrête ?

![webcup-pause-dej ><](https://bo.dev-freelance.fr/uploads/SL_3791011_thumb_9047d7b7f2.jpg)
Crédit photo : https://www.webcup.fr


Le mieux que je puisse vous conseiller, c'est de faire une pause à un moment (une sieste d'une heure ou deux). 🛌

De plus, je vais citer Abraham Lincoln : 

>Que l'on me donne six heures pour couper un arbre, j'en passerai quatre à préparer ma hache.

Prenez le temps d'élaborer une bonne stratégie, d'organiser les tâches, les développements etc en amont avec votre équipe. 

Un effet **waouw** peut rapporter énormément de points. Mais il faut sortir cet atout au bon moment, savoir quand est-ce que vous allez glisser ça dans votre application. Réussir à maîtriser l'effet de surprise.

#### Eviter les erreurs

Avec le temps, j'ai compris que ce qui coûte très cher à beaucoup de participants, c'est souvent les erreurs. 
**Les erreurs peuvent coûter plus cher que le fait de faire l'impasse sur les features, car vous risquez de perdre des points (au lieu de juste ne pas les avoir)**.

Pour éviter cela, il faut énormément de rigueur ! 

Revérifiez tout, l'orthographe, les liens, les boutons, les actions... Double checkez absolument tout (et à plusieurs) !

### Comment ça se passe en tant que Jury ? 

De l'autre côté de la table, le concours est tout autre. Vous arrivez généralement un peu plus tard et votre rôle sera de départager les candidats sur la base de leurs livrables.

Il faut savoir que nous n'avons pas accès au code source, nous irons vérifier nous même en tant que jury dev, que s'est-il passé dans le code pour qu'il y ait tel ou tel bug. Nous essayons d'interpréter et nous tentons même parfois quelques hacks pour vérifier si l'application est un peu "passoire" ou pas. 😈

Par ailleurs, je tiens à dire que même lors que je ne concours pas personnellement, j'ai toujours un peu le trac pour les candidats. Comme tout le monde on a aussi nos "chouchous" et on aimerait les voir faire un podium. 

Je pense même que je suis plus angoissé de devoir évaluer ces derniers, que l'être moi-même. Lors de nos tests, on se dit "Ahhh cette fonctionnalité n'est pas facile, c'est ici que tout va se jouer. J'espère vraiment que ça va passer et du premier coup...". La tension est à son comble !

Nous notons selon une grille et l'équipe webcup a pensé à beaucoup de choses : 

- le responsive
- l'accessibilité
- la lisibilité
- les fautes
- l'effet waouw
- etc...

**Les fonctionnalités comptent mais pas que ! De même, certaines sont plus importantes que d'autres**. 

Une fois noté, les résultats du jury seront additionnés pour désigner le vainqueur. 

### L'objectif du concours 

Au-delà de se challenger en tant que candidat, les objectifs du concours sont diverses. Vous pourrez tester vos compétences sous pression, avec des changements de dernières minutes. Cette compétition n'est pas seulement amusante, il y a de nombreux lots à gagner chaque année. 

L'association **Webcup** le dit : ce concours révèle des talents. 

**Des équipes inconnus arrivent à livrer des choses incroyables et en tant que jury, on est toujours surpris du niveau de ces équipes**. 

Avec le temps, j'ai compris autre chose...

Dans un projet d'application en entreprise, vous avez :

- une équipe avec laquelle il faut réussir à évoluer
- un date de sortie (donc une limite)
- des choix à faire sur les fonctionnalités à conserver pour sortir dans les temps
- des points essentiels sur lesquels vous n'avez pas droit à l'erreur
- une fatigue cumulée de toutes les tâches que vous aurez à gérer
- la pression d'une attente client sur les épaules

**Donc pour résumer, la Webcup, c'est un condensé d'expérience de toute votre vie de développeur que vous vivrez en seulement un jour**.

### L'équipe incroyable derrière de ce projet

Pour un concours génial, il faut une équipe géniale. 

Et c'est le cas avec l'association Webcup et les bénévoles qui agissent chaque année pour le changement numérique. Cette association fait de nombreux événement, ateliers, formations, autour de la tech pour former et transmettre. 

![Fabien-Degieux-Webcup ><](https://bo.dev-freelance.fr/uploads/Fabien_Degieux_5_038a0f2ad4.jpg)
Sur cette photo : Fabien Degieux du staff Webcup.


![alan-chakri-webcup ><](https://bo.dev-freelance.fr/uploads/alan_760caf852d.jpg)
Sur cette photo : Alan Chakri le président de l'association 


Je vous invite à consulter [leur site web](https://www.webcup.fr/) pour réaliser vous-même l'ampleur du travail de cette communauté. Tous ces membres (il y en a trop pour tous les citer), font chaque année le maximum pour faire profiter aux jeunes de leur expérience et faire s'exprimer les talents.

Alors pour tout leur travail, depuis des années, sans broncher face aux difficultés, je leur dis : un grand **MERCI** !

large_markus-spiske-uqeaZXZkquw-unsplash.jpg

medium_markus-spiske-uqeaZXZkquw-unsplash.jpg

small_markus-spiske-uqeaZXZkquw-unsplash.jpg

thumbnail_markus-spiske-uqeaZXZkquw-unsplash.jpg

markus-spiske-uqeaZXZkquw-unsplash.jpg

La Webcub est un concours Web où l'on a 24h pour réaliser un projet. Les participants peuvent concourir seuls ou en équipe et au bout de 24 heures, leurs travaux sont présenter aux membres du jury qui décideront de quels projets ont retenu leur attention. Je vous raconte tout ici...

J'ai été jury lors de la Webcup Réunion 2022

## Pourquoi préparer sa machine pour le code ?

Lorsque l'on a pas d'outil, on perd énormément de temps à faire les choses. Logique !

Imaginez-vous aujourd'hui enfoncer des clous à la main ou encore avec un gros caillou ? 🤔

Non, c'est absolument impossible. C'est pourquoi si vous voulez vous mettre au code, il vous faut préalablement installer des choses sur votre machine !

Dans cet article nous allons installer **Node.js**, mais aussi **Docker** et **Docker-Compose**. 

**Node.js** vous servira à coder, et Docker se chargera du déploiement de containers.

Ici nous ne parlerons pas d'IDE (le programme que vous utiliser pour coder), personnellement j'utilise [VSCode](https://code.visualstudio.com/) ou n'importe quel outil de [Jetbrains](https://www.jetbrains.com/) fera l'affaire. 

### Installation de Node.js

Si vous codez en javascript que ce soit pour du frontend ou du backend, il y a de fortes chances que vous ayez à installer **Node** sur votre machine. Oui, à la base **Node** c'est surtout pour exécuter du code Javascript sur un serveur sans avoir besoin de navigateur, mais détrompez vous, **Node.js** ne sert pas qu'à faire du backend. 

Depuis l'ascension des librairies compilés tels que : **React**, **Vue** ou **Angular**, vous ne pouvez plus vous passer de **Node.js** qui sert à compilé le code source écrit en Javascript interprétable sur votre navigateur.

#### Comment je m'y prends pour installer Node.js ?

J'ai remarqué que d'un projet à l'autre les versions de **Node.js** sont toujours différentes. 
Il est normal lorsqu'un projet est en production de gérer les mises à jour avec prudence, afin de garder toujours compatible les librairies, etc... Cependant, rien ne vous empêche sur vos projets personnels de faire des tests et passer à la version supérieur sans plus attendre.

C'est pourquoi lorsque j'installe **Node.js**, je ne l'installe jamais directement sur ma machine. Je passe par un gestionnaire de version pour, j'ai nommé : **NVM** (comme Node Version Manager).

#### Installer NVM sous Linux ou Mac OSX

Je vous écris ici la procédure préconisée par [les créateurs de NVM](https://github.com/nvm-sh/nvm) : 

```
# Installation via curl
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash
```

ou

```
# Installation via wget
wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash
```

Les deux font exactement la même chose.


Une fois installé, n'oubliez pas d'exporter **NVM** afin de pouvoir vous en servir dans votre terminal : 

```
export NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s "${XDG_CONFIG_HOME}/nvm")"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
```

#### Installer NVM sous Windows

N'hésitez pas à parcourir la documentation [nvm pour windows](https://github.com/coreybutler/nvm-windows#installation--upgrades).

Il vous faudra [télécharger une release](https://github.com/coreybutler/nvm-windows/releases).

Décompresser l'archive et installer le fichier **nvm-setup.exe**.

Une fois que **NVM** est installé, n'hésitez pas à tester directement dans un **Power Shell** : 

```
nvm ls
```

#### Utilisation de NVM

Vous pouvez désormais installer toutes les versions de **Node** que vous voulez !

```
# Installation de la version 16 de node
nvm install 16

# Installation de la version 14 de node
nvm install 14

# Faire de la v16 la version de node par défaut
nvm alias default 16

# Basculer à la version 14
nvm use 14
```

Pour information, à chaque fois que vous installez une nouvelle version, vos paquets globaux sont à réinstallé car cette version n'existait pas jusqu'à présent. C'est à dire que si vous voulez réinstaller **yarn**, il faudra refaire : 

```
npm i -g yarn
```

### Pourquoi utiliser Docker ?

**Docker** sert à déployer des containers sur votre machine, c'est à dire des blocs dans lesquels on va isoler certains processus, comme des programmes, des serveurs etc... 

De la même façon que vous utilisez des machines virtuelles pour pouvoir isoler des tests, ou déployer une version d'un système différent de celui de votre OS, etc... **Les containers servent à dissocier votre machine physique de ce qui tourne sur cette machine**. 

Et l'idée est d'autant plus ingénieuse que vous n'aurez pas besoin des couches d'interprétation basse comme c'est le cas pour les VM, Docker utilise votre système comme base, mais se propose d'isoler tout ce qui va tourner sur les couches supérieurs de votre système. 

De même, il s'agit de quelque chose de beaucoup plus léger qu'une VM. Lorsque vous démarrez une machine virtuelle, vous ponctionnez de la ressource physique depuis votre machine. Cela signifie que vous allez réquisitionner 2go de Ram, 2 CPU, un peu d'espace disque pour votre machine (que vous l'utilisiez ou non). 

A la différence, les containers tournent sur une couche supérieur à votre système d'exploitation, et ils peuvent prendre de la ressource uniquement en cas de besoin. Cela signifie tout simplement que votre machine pourra lancer sans problème une centaine de container en parallèle, là où elle aura du mal à dépasser les 4 VM en simultané.

On l'utilise généralement pour les serveurs HTTP comme Nginx, ou les serveurs de base de données. Cela vous permet de mettre à niveau votre container et voir si elle est toujours compatible avec le reste et dans le cas contraire vous pourrez revenir en arrière sans avoir de gros soucis. Pour aller plus loin, vous pourrez même lancer 5 serveurs Nginx ou 10 serveurs MySQL, chacun pointant sur des ports réseaux différents, sans créer de conflit avec une autre instance.

**L'idée est de pouvoir cloner, démarrer, arrêter les containers sans contraintes pour tout ce qui tourne sur votre machine.**

![docker-concept ><](https://bo.dev-freelance.fr/uploads/ezgif_5_6a45a382de_696f382182.png)

### Installation de Docker

J'utilise la community edition de Docker : 

[Docker pour Linux](https://docs.docker.com/engine/install/ubuntu/)
[Docker pour Windows](https://docs.docker.com/desktop/install/windows-install/)
[Docker pour Mac OSX](https://docs.docker.com/desktop/install/mac-install/)

Puis j'installe Docker-Compose.

#### A quoi sert Docker-Compose

**Docker-Compose** est un outil qui permet de gérer votre organisation de containers Docker via des fichiers. Cela signifie que vous allez pouvoir sauvegarder toute votre config dans un fichier que vous pourrez ensuite versionner. Car sans lui, **Docker** se configure en tapant des commande avec des options directement dans un terminal, donc ce n'est pas l'idéal pour visualiser si tout est OK.

Autrement dit, **Docker-Compose** est à **Docker** ce que la visseuse-dévisseuse est au tournevis. 

#### Comment installer Docker-Compose ?

Sur **Mac OSX** et sur **Windows**, **Docker-Compose** est livré avec le package de **Docker**. (Incroyable ! 😱)
Sous **Linux**, vous devez le faire vous même :

```
# Pour Ubuntu 20
sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

sudo chmod +x /usr/local/bin/docker-compose
```

Vous pouvez maintenant vérifier que tout est ok avec cette commande : 

```
docker-compose --version
```

### Conclusion

Avec ces outils maintenant installé sur votre machine, vous êtes fin prêt pour des centaines de milliers de lignes de code. A vous la créativité sans limite ! 😝

towfiqu-barbhuiya-B3ssnD2ki64-unsplash.jpg

large_towfiqu-barbhuiya-B3ssnD2ki64-unsplash.jpg

medium_towfiqu-barbhuiya-B3ssnD2ki64-unsplash.jpg

small_towfiqu-barbhuiya-B3ssnD2ki64-unsplash.jpg

thumbnail_towfiqu-barbhuiya-B3ssnD2ki64-unsplash.jpg

Il y a un certain nombre de programmes qu'il faut avoir installer sur votre machine pour commencer à coder. Il existe encore beaucoup d'ordinateurs sur lesquelles il n'y a absolument rien pour commencer dans de bonnes conditions. Qu'à cela ne tienne, nous allons y remédier.

Le minimum syndical pour coder sur sa machine

## Pourquoi Trello ? 🤔

[Trello](https://trello.com/) est une application fascinante qui a donné une vraie direction à l'organisation de projets via des outils web très simples. Je dirais même que toute sa technicité se trouve dans sa simplicité. C'est un outil que j'aime beaucoup, en tant qu'utilisateur ou aussi pour sa partie code.

Il y a plusieurs défis à relever sur **Trello**, la partie temps réel, ainsi que des éléments de design comme le drag-and-drop etc... que je trouve génial. 

Un excellent moyen de s'exercer !

### Les outils que je choisis pour faire ce projet ⚒️

Une fois n'est pas coutume je vais me servir de **Meteor.js** pour pouvoir gérer à ma place le temps réel via le système de **Tracker**. 

Toujours en full **Typescript**, bien entendu !

Pour la partie graphique j'utilise **React** ainsi les librairies suivantes : 
- **twind** : j'en ai parlé dans [un précédent article](https://dev-freelance.fr/dev/tailwindcss-et-classnames-en-un-seul-package)
- **react-hook-form** : pour accélérer la création des formulaires
- **moment** : pour manipuler et formater les dates
- **sweetalert2** : pour les modals de confirmation
- **react-icons** : pour les icônes

Pour le stockage j'utilise **MongoDB**.

### Quelles sont mes observations après avoir développé ce prototype 🧐

Le but n'est pas de refaire Trello en entier, j'ai mis de côté la partie de gestion de compte utilisateurs.

Ce n'est pas le prototype le plus compliqué du monde si on se contente d'implémenter les fonctionnalités suivantes : 

- Création de boards
- Création de listes attachées à un board
- Création de tâche attachées à une liste
- Mise à jour du board (cascading update...)
- Suppression d'un board
- Suppression d'une tâche
- Suppression d'une liste

#### Les difficultés rencontrées 😅

Les mécaniques les plus techniques à gérer sont la partie Drag and Drop, j'ai compté 3 types de cas : 
- On déplace une tâche d'une liste à l'autre
- On déplace une tâche dans la même liste
- On déplace la liste entière

#### Ce que j'ai appris 🤓

La gestion du drag and drop en React est assez subtile, notamment le fait de gérer où est-ce que l'on va effectuer le drop, gérer les événements et savoir quand et pourquoi il faut arrêter les propagations. Je le redis, tout cela est subtil et vous demandera quelques essais avant que cela soit fructueux !

### On regarde le résultat ? 😁

Au bout de 4 heures environ, j'ai pu avoir des essais fonctionnels de bout en bout, et le tout avec le temps réel !


<iframe width="100%" height="400" src="https://www.youtube.com/embed/haNvdSWpZAI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen onload="this.style.height=(this.contentWindow.document.body.scrollHeight+20)+'px';this.stype.width='100%';"></iframe>

Je reviendrai sur cet exercice avec un format différent pour vous montrer en détails comment j'ai pu arriver à ce résultat.

A très vite 😃

large_jo-szczepanska-5aiRb5f464A-unsplash.jpg

medium_jo-szczepanska-5aiRb5f464A-unsplash.jpg

small_jo-szczepanska-5aiRb5f464A-unsplash.jpg

thumbnail_jo-szczepanska-5aiRb5f464A-unsplash.jpg

jo-szczepanska-5aiRb5f464A-unsplash.jpg

Ce que je fais pour pratiquer le développement, c'est de créer ou recréer des applications existantes. N'exagérons rien, je ne propose pas autant de features que ces dernières, mais le but est de réaliser les fonctionnalités qui me plaisent chez ces applications un temps assez court (quelques heures ou quelques jours).

Je réalise un clone de Trello avec Meteor, React et Mongo

## Pourquoi Tailwindcss ? 🤔

Il existe déjà des librairies **CSS** tels que **Bootstrap**, **Bulma**, **Ui-kit** etc... Ces librairies ont apporté leur lots de nouveautés notamment le passage à la grille de N colonne pour organiser ses vues de manière horizontale. 

Mais ces librairies ont déjà une d'identité visuelle forte et lorsque l'on veut créer quelque chose de personnalisé, il faut souvent importer ces librairies (qui sont déjà lourdes), puis les personnaliser (ajouter un custom CSS qui alourdi d'autant plus notre projet).

**Tailwindcss** propose une approche de compilation à la volée qui va garder uniquement l'essentiel de ce que nous utilisons dans le projet. 
Cette approche permet d'optimiser la taille de nos livrables, de plus **Tailwind** est une alternative qui laisse place à notre créativité en matière de design car cette librairie ne fourni que les outils. C'est à vous de créer vos composants etc...

### A quoi sert Classnames ? 🧐

[Classnames](https://www.npmjs.com/package/classnames) est un paquet qui permet les classes d'un composant de manière très simple. Cette librairie permet d'ajouter les classes conditionnellement et de concaténer, etc....

```tsx
import cn from 'classnames'

type ComponentProps = {
 bold: boolean
}

const Component = ({  bold }: ComponentProps) => {
 return (
 <div className={cn('rounded-lg', 'bg-white', { 'font-bold': bold, 'font-semibold': !bold })}>
 // contenu...
 </div>
 )
}
```

Dans cet exemple, la classe au moment du rendu sera 'rounded-lg bg-white font-semibold' ou 'rounded-lg bg-white font-bold' en fonction de la valeur de la propriété bold. Et on peut continuer à mixer les propriétés en ce sens. 

D'ailleurs, il n'est pas obligatoire de passer une seule classe par argument, on aurait très bien pu mettre ensemble les deux premiers arguments : 'rounded-lg bg-white'.

### Faire aussi bien que Tailwindcss et Classnames réunis 🤝

Le paquet [twind](https://www.npmjs.com/package/twind) prend le meilleur des deux mondes. Et c'est littéralement la révolution !

Commencez par installer le paquet : 

```
yarn add twid
```

Puis vous pouvez vous en servir comme ceci : 

```tsx

const Title = () => {
 return (
 <h1 class="${tw`font-bold text(center 5xl white sm:gray-800 md:pink-700)`}">
 This is Twind!
 </h1>
 ) 
}
```

Remarquez que dans cet exemple qui vient de la documentation de **twind**, on utilise text(...) comme une fonction. Tout ce qui se trouve entre les parenthèses seront concaténés par **text-**. **Le code est donc encore plus court à écrire pour un résultat similaire.**

Pratique non ?

En n'oubliant pas d'installer l'extension vscode pour avoir l'intellisense : 

![twind-extension-vscode ><](https://bo.dev-freelance.fr/uploads/Capture_d_ecran_de_2022_07_20_09_29_35_e2b454b62c.png)

Vous pourrez bénéficier ensuite de l'auto-complétion avec le raccourci "CTRL + Space" (sous linux)

![twind-intellisense-usage ><](https://bo.dev-freelance.fr/uploads/intellisense_40c38468f1.gif)

En tout cas, cette librairie m'a convaincu et j'ai fait le choix de m'en servir pour mes projets futurs. 😃

large_sigmund-F_m44ut3XTw-unsplash.jpg

medium_sigmund-F_m44ut3XTw-unsplash.jpg

small_sigmund-F_m44ut3XTw-unsplash.jpg

thumbnail_sigmund-F_m44ut3XTw-unsplash.jpg

sigmund-F_m44ut3XTw-unsplash.jpg

Tailwindcss c'est un peu la librairie CSS parfaite qui permet d'utiliser des classes au lieu de devoir déclarer du CSS. Cette librairie fait gagner un temps fou et plus le temps passe à l'utiliser, plus votre vitesse de programmation. Aujourd'hui nous allons voir une librairie qui cumule Tailwindcss et Classnames.

Tailwindcss et Classnames en un seul package

## Créer son projet de A à Z quand on n'est pas développeur ⌨️

Aujourd'hui plusieurs solutions s'offrent à vous pour créer votre Proof of Concept (POC). 

Nous allons comparer les différentes solutions qui s'offrent à vous, en passant par les outils no-code, aux prestataires ou au fait de créer votre produit vous-même.

Puis nous détaillerons les étapes clés pour la réalisation de votre application.

### Les solutions no code 📱

Le marché a compris que beaucoup de gens souhaitaient se lancer mais peu ont les compétences pour pouvoir le faire réellement. 

Pour autant est-ce un problème ?

Plus maintenant ! **Les développeurs ont créé des outils no-code qui permettent à des non devs de pouvoir donner vie à leur projets**. 

Qu'est-ce qu'un outil no-code ?

C'est une solution qui va vous permettre de créer vos applications grâces à des vues simples et du glisser-déposer... 

Est-ce la fin des développeurs ? 

Les gens pensent : "Oh mon Dieu 😱, demain le métier de développeur sera obsolète parce qu'il y a des outils no-code pour remplacer les développeurs !". 

Et ben non, les développeurs n'auront qu'à se mettre à développer eux aussi des outils no-code, donc cela n'est en rien un frein à notre métier. 

Tout comme l'IA aujourd'hui, puisque l'on commence à créer des applications à partir d'intelligence artificielle. Il suffit de passer sur du développement d'IA une fois que le marché sera saturé par ce genre de solutions. Les développeurs, s'adaptent, et derrière chacun de ces outils, il y a toujours des développeurs, rassurez-vous, on n'est loin d'être sur la sellette. 😂

Lorsque je tape solution no-code sur google, j'ai cette liste de produits qui s'affichent : 

- [Out Systems](https://www.outsystems.com/)
- [Flutter Flow](https://flutterflow.io/)
- [No Code](https://www.nocode.tech/category/app-builders)
- [Kiss Flow](https://kissflow.com/)

Et j'en passe...

#### Quels sont les limites (actuelles) des solutions no-code ? 😢

Il y a des raisons pour lesquelles je ne peux pas recommander de passer directement sur des solutions no-code. Bien sûr ces solutions s'améliorent chaque jour, les développeurs travaillent d'arrache-pied pour régler ces problèmes. Mais nous allons les lister tout de même : 

##### Le prix 💸

le prix est affolant, la plupart des solutions sont très chères (jusqu'à 1500€ /m) et en plus ce prix évolue en fonction du nombre d'utilisateurs (cela veut dire que ces solutions vous prendront une partie de votre marge tout au long de votre croissance). Par opposition, certains prototypes vous coûteront quelques milliers d'euros, soit quelques mois d'abonnement, ensuite toute votre marge sera conservée.

##### La propriété intellectuelle 📃

Vous ne possédez pas le code source, mais uniquement votre acquisition client. C'est bien d'avoir une grosse base client, et cela a beaucoup de valeur, en revanche lors d'une revente, cette acquisition vous rapporte beaucoup moins que si vous avez des brevets ou si vous possédez votre code source (dans ma carrières j'ai déjà travaillé en tant que "cleaner" de code source en vue d'une acquisition, il y a un audit pour estimer la valeur de la boite sur de grosses transactions).

##### La perte de contrôle 🧗

Cette couche qui vous permet de créer vos applications crée aussi une couche d'opacité sur ce qu'il se passe réellement côté code. Cela rend les problèmes plus difficiles à identifier et vous êtes tout autant exposé aux bugs (comme sur un projet traditionnel que vous développez). C'est à dire que vous avez le même niveau de risque, pour moins de maîtrise. 

##### Les supports semblent limités 🖥

La plupart des solutions ont l'air de mettre le paquet sur les apps mobiles, ce n'est pas totalement une mauvaise chose. La majorité des utilisateurs sont sur mobile, mais pourquoi ne pas être directement multi device ? C'est à dire tablette, PC et mobile ! Tout dépend ensuite du marché cible. Si vous faites un outil destiné au B2B (donc les professionnels) il y a de fortes chances pour que votre outil soit surtout utilisé sur un PC (comme dans le cadre du travail). Donc limiter à l'utilisation mobile reviendrait à se fermer des portes quand on sait que les professionnels travaillent essentiellement sur des ordinateurs et pas des téléphones. 

#### Les bons côtés du no-code 😃

Je ne veux pas dépeindre un portrait sombre de cette solution qui comporte toutefois de bons côtés : 

- Vous pouvez mettre en place quelque chose et toucher un marché pour tester une idée
- Vous décider du besoin et du workflow
- Vous obtenez des compétences de création sans avoir eu à apprendre un métier complexe 

Au final, cette solution n'est pas si mal si vous arrivez à atteindre votre objectif, c'est à dire lancer votre produit et à condition que cela ne vous coûte pas un rein. 

### Développer ou faire développer sa solution 👨‍🔬

Vous décidez de faire vous-même ou faire faire votre développement par un freelance ou une agence. Il y a tout de même des choses à savoir et quelques raccourcis à prendre pour vous faire gagner du temps et de l'argent.

Les langages les plus utilisés en France sont **Node** et **PHP**. 

La plupart des vues utilisent : **HTML**, **CSS**, **Javascript** et **Node.js** utilise déjà Javascript, ce qui signifie que **Node.js** est le langage où vous avez le plus de chances de tomber sur un **profil fullstack** (qui va s'occuper de coder les fonctionnalités serveurs "backend" et les vues "frontend"). 

Comment choisir au mieux ? 

![choix-stack-technique-node-php ><](https://bo.dev-freelance.fr/uploads/stack_drawio_33c66b415d.png)

Lorsque votre projet comporte une partie temps réel, que ce soit notification temps réel sur écran, chat, vidéo, audio, etc... Il est recommandé d'utilisé un langage comme Javascript qui est orienté événement. **PHP** est un langage synchrone qui fait très bien l'affaire lorsqu'il faut coder une API qui fait des enregistrements dans une base de données. 

Une chose est sûr moins vous avez besoin de développeurs pour lancer votre projet, moins vous aurez à mettre la main à la poche. Maintenant, tout dépend du compromis que vous êtes prêt à faire sur les délais de livraison. 

**Si vous êtes vous-même développeur, faîtes simple. Restez dans votre domaine de compétence tant qu'il répond à votre besoin. Si vous faîtes du PHP, du Ruby, du Python, etc... Passez directement à la suite**. 👍

Si vous devez choisir un développeur **PHP**, demandez à utiliser le framework **Laravel** ou **Symfony** (les plus répandus sur le marché), pour ne pas être pieds et poings liés à un seul développeur.
Si vous choisissez un développeur **Node.js**, demandez à utiliser **Next.js** pour avoir le frontend **React** de la même façon. Sinon travaillez avec quelqu'un qui maitrise des technologies comme **Express.js** pour faire l'API et le front en **React** ou **Vue.js**.

Pour le frontend, je ne partirai pas sur autre chose que **React** ou **Vue.js** car **Angular** est une solution unifiée et est un peu plus rare sur le marché. Encore une fois, le but de cette démarche est de ne pas vous bloquer pour que votre projet puisse être maintenu par un plus grand nombre de développeurs.

#### Formuler son besoin ✏️

Pour obtenir une estimation claire et précise vous avez besoin d'élaborer un cahier des charges ou du moins un document de spécification des besoins.

Qu'est-ce que vous souhaitez réaliser ? A quoi sert votre application ? 

Il est beaucoup plus simple pour un développeur d'avoir une idée de comment faire ce que vous voulez si vous êtes précis dans votre demande et s'il comprend votre objectif. Ainsi, vous ne devez pas répondre à la question **"quoi ?"** (un produit qui fait telle chose ou telle autre chose...) mais répondre à la question "**comment ?**" (nous souhaitons répondre à tel besoin en faisant...). C'est déjà beaucoup plus précis comme demande.

Expliquez en 1 paragraphe le problème que vous souhaitez résoudre. En étant totalement réaliste, si cela dépasse 10 lignes, votre projet va vous coûter un bras. 😂

##### Préparer la base de données 📝 

Si votre application doit stocker des éléments dans une base, quels sont les données que vous souhaitez stocker et quels sont les champs associés ? 

Par exemple : 

Nous souhaitons stocker des utilisateurs avec les champs suivants : 
- Nom
- Prénom
- Email
- Profession

Nous souhaitons stocker les postes occupés par ces utilisateurs : 
- Utilisateur concerné
- Nom entreprise
- Intitulé profession
- Date début
- Date fin

etc... 

Pour aller plus vite lors de l'élaboration d'un **POC**, je vous recommande l'utilisation de **MongoDB**. Il s'agit d'une base de données plus souple qui vous permettra de faire évoluer votre besoin pendant les développements.

##### Envoi de documents 📄

Dans votre application, est-ce que vous devez envoyer des documents en tant qu'utilisateur ? Mettre en ligne des documents PDF ? Des vidéos ? Des photos ? 

En fonction des réponses, cela signifie qu'il va falloir mettre en place des espaces de stockage, cela peut aussi influencer le prix de votre prototype. Car il faudra inclure non seulement des développements, mais aussi le prix du stockage en ligne et de la distribution. (Par exemple : mettre en place un serveur de streaming coûte plus cher en nombre de serveur qu'une plateforme de distribution de photo comme fotolia ou istock).

##### Workflow et Wireframe 📋

Comment souhaitez-vous organiser votre projet ? Quels sont les écrans ? Comment ces écrans communiquent-ils entre eux ? 

Il est plus simple de faire estimer un projet lorsque tout cela est déjà bien défini. En général j'essaye de faire une cartographie des écrans en reliant entre eux les écrans connectés. Cela me donne un arbre de connexion inter-écrans. Pour réaliser ce schéma j'utilise une application en ligne que je recommande souvent : [App Diagrams](https://app.diagrams.net/).

![connexion-inter-ecrans ><](https://bo.dev-freelance.fr/uploads/screen_connections_drawio_672f183ec3.png)

Ce schéma permet de savoir plusieurs choses :
- Le nombre minimum d'écrans pour pouvoir sortir votre projet
- Le fait de devoir gérer des espaces publics ou privés

Il est possible d'aller encore plus loin, où vous pouvez, par écran faire la cartographie de tous les appels API que vous souhaitez faire. Pour maîtriser quels sont les requêtes nécessaires pour chaque écran.

Chaque écran fera l'objet d'au moins une tâche sur votre **To-Do list**. Vous pourrez, bien sûr choisir de découper davantage afin d'avoir quelque chose de plus digeste pour commencer à travailler.

Pour chaque écran, vous devez élaborer un **wireframe**, c'est à dire une maquette qui va guider votre création graphique et vous permettre de positionner vos éléments.

![wirefrape-unsplash ><](https://bo.dev-freelance.fr/uploads/sigmund_4_U_Gmm3_WR_Uo_Q_unsplash_af7d465e85.jpg)

Lorsque vous faîtes vous-même la réalisation de votre projet, vous pouvez passer cette étape, mais sachez qu'elle va simplifier votre vision de la page et vous permettra plus facilement de mettre en place votre vue sous forme de brique réutilisable. 

**Ce travail va permettre de simplifier largement les estimations car vous avez une idée précise de ce dont vous avez besoin**. Plutôt que de recevoir une fourchette globale pour tout le projet, vous pouvez demander l'estimation en temps la plus haute pour chacune de ces pages. De cette façon vous obtiendrez le temps total que cela demande pour réaliser votre projet.

##### Gestion de votre application ⚙️

Nous venons de travailler sur des vues et la partie affichage avec laquelle vos utilisateurs vont interagir. Il faut maintenant penser aux vues administrateurs de votre projet. 

Certains projets arrivent à se passer de cette partie car on peut directement insérer des données en base etc... C'est à dire prendre quelques raccourcis quand il s'agit de l'administration de votre projet.

**Cependant, si votre projet doit être administrable par un utilisateur, est-ce qu'il vous faut des écrans dédiés à l'administration ? (Ce que l'on appelle dans le jargon : un backoffice)**.

Si la réponse est oui, je vous invite à recommencer le processus Workflow et Wireframe, cette fois-ci pour les vues d'administration.

#### Déployer votre solution 🚀

Une fois que le prototype est codé, il vous faut livrer tout ça. 

- Soit vous décidez de tout faire vous même en optant pour un VPS (meilleur rapport qualité/prix du marché), 
- Soit vous sous-traitez cette demande. 

Si dès le départ vous êtes sur une solution orienté cloud serverless, cela vous coûtera un peu plus cher mais au moins vous n'aurez rien à maintenir et à monitorer. 

Comptez aussi de quoi prendre un nom de domaine en moyenne 10€ / an (cela dépend de l'extension souhaitée).

Avec mon VPS j'affiche un prix TTC par an, domaine compris de 58 €.

Pensez également au prix du déploiement si vous ne le faîtes pas vous même, sur la base du temps de prestation. 

### Conclusions 👨‍⚖️

Nous avons vu les avantages et les inconvénients des outils no-code, cela reste une option envisageable si vous n'êtes pas développeur. Ou sinon, vous pouvez travailler vous-même pour votre solution ou sous-traiter la réalisation de votre produit. A l'instant T, cela peut vous sembler plus cher que la solution no-code, mais dans la durée il s'avère que non, d'autant plus vous serez propriétaire du code source et la valeur dégagé par votre produit sera supérieure. 

Gardez en tête que la plupart des solutions no-code ont tendance à établir les prix en fonction du nombre d'utilisateurs. Cela aura tendance à faire plafonner vos résultats si ceux-ci évolue en même temps que votre produit. 

**Si vous voulez dégager plus de marge, je vous conseille d'opter pour une solution dont les coûts fixes sont les plus bas**.

### Après le prototypage ? 🔭

Une fois que votre prototype est fini, vous pouvez le faire évoluer vers une version plus pérenne. La première chose à faire est d'atteindre un marché, vous aurez préalablement travaillé votre communication et votre acquisition client. 

C'est toute cette partie marketing, et la diffusion de votre produit qui doit occuper votre esprit.

Pour ce qui est du produit en lui même, vous pouvez l'améliorer de manière itérative. De petits cycles vont améliorer une partie de votre produit, vous permettra de stabiliser votre application en même temps que vous prendrez des parts du marchés.

Par exemple vous pouvez choisir : 
- d'ajouter une fonctionnalité
- de refaire le design de certains écrans
- d'améliorer certaines fonctionnalité pour encaisser une plus grosse charge client
- etc...

**L'amélioration sera une tâche continue de votre projet après son lancement**. Vous pourrez choisir de tout faire en parallèle (en constituant une équipe, ou en y travaillant à temps plein), ou étaler ces choix dans le temps. Voilà pourquoi, vous n'avez pas besoin de tout améliorer en amont, mais simplement de sortir quelque chose. 

Plus votre projet et les étapes le constituant seront clairs dans votre esprit, plus il sera simple de le réaliser. Et pour reprendre Napoleon Hill : **"Tout ce que le mental de l’homme peut concevoir, il peut le réaliser"**.

large_callum-hill-NGGkGzslIaM-unsplash.jpg

medium_callum-hill-NGGkGzslIaM-unsplash.jpg

small_callum-hill-NGGkGzslIaM-unsplash.jpg

thumbnail_callum-hill-NGGkGzslIaM-unsplash.jpg

callum-hill-NGGkGzslIaM-unsplash.jpg

Comment vous y prendre si vous souhaitez créer votre application ou votre plateforme ? C'est une question à laquelle il n'y a pas qu'une seule réponse possible mais je vais tenter de répondre en argumentant au maximum.  

Comment réaliser votre projet étape par étape

## Pourquoi parler du déploiement de son code ? 🤔

Les développeurs ont trop tendance à mettre de côté cette compétence clé pour la création d'un produit (web, application, etc...). Lorsque vous travaillez des semaines, des mois sur quelque chose, pour que tout cela ait un sens, il faudra déployer à un moment où un autre. 

Soyez sûr qu'à ce moment là, on ne parle pas de faire un **npm dev/yarn dev** dans sa console en pensant que ça va régler le problème.
Le déploiement n'a rien à voir avec le fait de faire tourner du code sur sa machine pendant les développements. 

Premièrement ces scripts font beaucoup de choses automatiques pour vous, comme le **Hot-Module-Reload** (**HMR**), la compilation du code pendant la modification pour avoir une page web "live" avec votre service. Sachez que c'est une grosse erreur de lancer sa production en mode dev, car le **HMR** ne compresse pas le code source pour rendre les **stack** et **debug** lisibles. Cela signifie que vous êtes en train de livrer des sources plus lourdes et plus longues à charger pour vos utilisateurs... 😕

Mais aussi le lancement de votre serveur en mode dev affiche énormément d'informations, que vous ne voulez pas forcément afficher à vos utilisateurs. Parmi ces informations, vous retrouverez les logs d'erreurs, les stack trace en cas de bug, peut être même l'affichage en clair de log d'informations contenants des token etc... Bref beaucoup de mauvaises pratiques pour une production. Faire une vraie "**MEP**" comme on dit dans le jargon (pour mise en production), c'est un travail.

Cette compétence n'est pas simple, elle requiert : 
- de la compréhension : qu'est-ce que vous déployez, 
- de la vigilance : savoir mettre en place du monitoring, 
- du savoir faire : maîtriser son système d'exploitation, les versions, les compatibilités ou conflits
- de la veille : se tenir informé des failles, de l'évolution des packages

### Anticiper le déploiement ♟️

Lorsque vous codez, vous devez aussi anticiper sur cette étape ultime de votre création, la mise en production. Et le fait d'y penser d'avance se traduit par le fait d'intégrer au niveau du code plusieurs éléments qui dissocie d'avance la partie de code qui s'exécute pendant les tests et la partie de code qui s'exécute uniquement en production. 

Bien évidemment cela n'est pas toujours le cas. Il n'y a aucune obligation à exclure une partie du code de votre environnement de développement, mais cela arrive souvent. Par ailleurs, pour gérer de manière plus efficace les environnements, nous utilisons souvent un fichier d'environnement au niveau de la racine de votre projet. Ce fichier s'appelle par convention "**.env**" et les paquets comme [dotenv](https://www.npmjs.com/package/dotenv) nous permet de manipuler vos environnements au niveau du code plus facilement.

Dans ce fichier **.env**, on va retrouver de manière générale : 
- la "connection string" vers la base de données
- les clés API utilisés dans le projet
- etc...

Il s'agit d'une simple association clé/valeur sous cette forme : 

```
DATABASE=mysql://user:pass@host:port/dbname
API_KEY_A=wIenv_0nw9418QnqzlRIciap_@
API_KEY_B=W34WnfiroVJrizerO95ç0_JVnernazo
```

Et pour les utiliser au niveau du code après avoir importé votre librairie **dotenv**, vous pourrez tout simplement faire : 

```javascript
const pg = require('knex')({
 client: 'pg',
 connection: process.env.DATABASE,
 searchPath: ['knex', 'public'],
});

const apiA = InitApiA(process.env.API_KEY_A);

// ....

```

⚠️ Mais du coup, puisque vous intégrez des clés sensibles à votre fichire **.env**, il convient de ne pas le versionner sur vos repository. Pensez à ajouter une ligne dans votre **.gitingore** afin de ne pas l'ajouter à vos commits. 

En général ce que je fais, c'est que je laisse un fichier de plus que je nomme **.env.sample** dans lequel je laisse une liste des clés sans valeurs de ce que j'ai besoin d'initialiser dans mon environnement. (Juste une sorte de rappel). 

```javascript
DATABASE=
API_KEY_A=
API_KEY_B=
```

### Effectuer le déploiement 🚀

Pour ce qui est du déploiement de votre projet, tout dépend de la direction que vous aviez pris au moment de la conception de votre solution. 

Est-ce que vous avez fait le choix de faire du développement traditionnel ou une **solution serverless** ? 

Ce que j'entends par **solution serverless**, c'est une solution qui repose essentiellement sur des services managés (**SaaS**), en gros du full cloud. C'est à dire que le provider s'occupe de la mise à disposition du service, de la montée en version, de l'hébergement et du monitoring. [On en avait parlé pour les bases de données.](https://dev-freelance.fr/dev/passer-de-frontend-a-backend-les-bases-de-donnees) Il en est de même pour la partie code. 

Avez-vous fait le choix d'un framework **Node** ou **PHP** traditionnel ou avez vous fait le choix d'un service de **cloud functions** ?

C'est à dire que vous créez des morceaux de codes qui vont être exécutés à des moments précis : 

- Lors de l'appel d'une route HTTP comme c'est le cas pour [Google cloud functions](https://cloud.google.com/functions) ou [Amazon lambda](https://aws.amazon.com/fr/lambda/)
- Lors d'événements spécifiques (création de fichier sur un espace de stockage cloud, appel en cascade après une **cloud function**, etc...)

Je n'ai pas de préférence particulière au niveau des services de **cloud functions**, j'ai testé les deux providers et j'aime beaucoup les deux. Je dirais juste qu'**Amazon** a décliné un peu plus ses outils, ce qui permet plus de souplesse, si vous optez pour la mise en place d'une solution cloud **Amazon**.

Ainsi, je pense que les deux solutions peuvent convenir à vos besoins si vous décidez de passer sur du **serverless** pour ne pas vous embêter avec le maintient d'un serveur et surtout de ses différents services (le serveur **HTTP**, l'instance de votre serveur de code, le serveur de base de données, le serveur de cache). 

Si vous passez sur une solution **serverless**, le déploiement est assez cadré. Vous ne risquez pas vraiment de vous perdre, car les procédures vous guident pas à pas. De plus, vous avez aussi des framework **Node.js** tel que [Serverless Framework](https://www.serverless.com/) qui est vraiment pas mal pour faire votre déploiement Amazon Lambda sans trop vous casser la tête. Le framework est très bien documenté et est open-source.

Vous avez aussi d'autres services managés tels que [Vercel](https://vercel.com/) pour **Next.js** qui va gérer toute la partie déploiement beaucoup plus facilement pour vous lorsque vous l'aurez associé à **Github**.

Le seul petit bémol pour les solutions managés, c'est le prix.

⚠️ **Il va falloir passer à la caisse, autrement dit tout le temps que vous ne passerez pas à maintenir vous même vos serveurs, vous allez le payer et forcément, le prix est un peu plus élevé qu'un service que vous maintenez vous-même.**

Pour vous donner un ordre d'idée, j'ai un projet assez basique qui tourne sur AWS depuis quelques années avec une stack : **API Gateway**, **Lambda Node.js**, **RDS PostgreSQ**L. J'utilise le serverless pour [cette application mobile](https://play.google.com/store/apps/details?id=com.versusdb.app) qui me coûte en moyenne 40 € /mois en SaaS, donc le coût, n'est pas négligeable.

---

D'un autre côté, vous pouvez opter pour une solution où vous allez vous même tout mettre en oeuvre. Elle vous demandera un peu plus d'efforts, de temps, de compréhension, mais au final, ce n'est pas plus mal non ? Non seulement, on a la maîtrise totale de ce que l'on fait, on apprend, mais en plus, cela nous fait faire des économies.

Avant d'entrer dans le détail des modes de déploiement, il faut savoir qu'en fonction des machines pour lesquelles vous optez, vous allez devoir faire les choses différemment. A l'époque, la plupart des serveurs étaient des serveurs **PHP** et ne proposaient pas beaucoup d'alternatives : 

- **Les serveurs mutualisés** : plusieurs clients se partagent une ressource machine, en sachant que l'on n'a pas besoin d'avoir une puissance de calcule énorme pour tous les types de services ou de sites.
- **Les serveurs dédiés** : disposer de la puissance de toute la machine rien que pour vos sites ou services.

Tout deux avec tout de même des limitations au niveau du réseau qu'il faudra finalement se partager depuis l'hébergeur, mais pas de panique, ces derniers disposent de connexion qu'un particulier de rêve pas d'avoir chez lui, donc au niveau des limites, on est très loin.

Aujourd'hui avec d'autres langages de programmation comme **Node.js** ou même un peu avant **Node** avec **Ruby on Rails**, on voit de plus en plus des serveurs privés virtuels (**VPS**). On va dire qu'il s'agit d'un mi-chemin entre le dédié et le mutualisé. 
Il s'agit de mutualiser les ressources machines mais, au niveau des services eux mêmes, chacun dispose de son service dédié, voire même d'une connexion **SSH** vers la machine.

Un **serveur dédié** ou un **VPS** vous donne tout deux un accès **SSH** vers la machine. Vous pourrez vous connecter via votre terminal et y effectuer toutes les opérations souhaités (installations, configurations, etc...).

En revanche cela demande de s'y connaitre un peu en serveur **linux**. Etant donné qu'il s'agit d'une machine, vous avez aussi le système d'exploitation à gérer. Très souvent vous serez sous linux, mais pour la distribution, vous devriez avoir le choix au moment de souscrire à la formule. Pour vous donner un ordre de grandeur, les VPS sont accessible avec des offres qui coutent environ 10€ / mois en moyenne. 

Il y a beaucoup d'hébergeurs entre **OVH**, **Scaleway**, **PulseHeberg**, **Gandi**, etc. 
Je pense tout de même que le meilleur rapport qualité/prix est **PulseHeberg**. Certes, le prix ne fait pas tout, mais au niveau du service c'est à dire la machine en elle même ainsi que la connexion, je suis satisfait. Tout le reste, je le fais moi, alors pourquoi payer plus cher ? 😅 

J'ai testé tous ces services de VPS sauf **Gandi** (un peu trop cher pour mon besoin).
Pour info chez **PulseHeberg**, je me retrouve donc avec **2 vCore** (vCore pour virtual core, environ 50% du temps machine d'un core standard), **2go de ram** (ce n'est pas beaucoup), **30go de SSD** (c'est largement suffisant pour ce que j'en fait) pour 4 € / mois. 🤠

#### Les différents modes de déploiement 🧐

A l'époque avec les **serveurs mutualisés**, les déploiements se faisaient encore via **FTP**. Il fallait envoyer fichier par fichier les sites et applications, via le protocole de File Transfert... Une méthode un peu archaïque à ce jour.

Mais cette époque est révolue. Depuis que l'on donne aux utilisateurs de plus en plus d'accès aux ressources machines, que ce soit sur les **serveurs dédiés** ou les **VPS**.

Puisque vous pouvez décider de ce que vous installez sur le serveur, au delà du langage de programmation, vous pouvez très bien mettre en place des outils de déploiement. 

#### Directement sur la machine 🚢

Si on décide de déployer notre serveur directement sur la machine. Ce n'est pas l'idéal car si l'on change de serveur, il faut tout refaire, mais cela reste une option. Dans l'idéal je recommanderai d'avoir des scripts de déploiements qui ne sont pas liés à la machine.

**Je préfère vous prévenir, peu importe la méthode que vous emploierez à terme, il est fort probable et recommandé de commencer par tout faire à la main (on va taper chaque commande nous même)**. 

On va se connecter sur le serveur et faire chaque étapes les unes après les autres : 
- installation des paquets systèmes et dépendances
- pull du projet
- configuration de l'env, les clés, etc...
- création du service sur **systemctl** (fortement recommandé !), d'autres personnes utilisent [PM2](https://pm2.keymetrics.io/) pour les projets **Node**
- lancement des services

Créez un fichier script sur le côté pour copier/coller les commandes à chaque étape de votre configuration serveur. En faisant cela, vous êtes en train de créer le script de déploiement. Il convient de grouper ensuite les parties de script afin d'isoler chaque étape de déploiement. En calquant la liste vue précédemment.

#### Sur des containers 🚚

Voici une autre approche qui consiste à déployer le serveur via des container **Docker**. Pour ceux qui ne connaissent pas du tout [Docker](https://www.docker.com/), je vous conseille de faire quelques recherches sur le sujet car cela en vaut la peine. 

⚠️ Attention pour cette partie, sachez que cela ne fonctionne pas avec tous les **VPS** (qui sont des **container** ou des **VM**), Docker ayant besoin de certains jeux instructions et autorisations... Pour les **serveurs dédiés**, vous pouvez y aller sans problèmes !

Docker vous permet de livrer votre code sous forme de briques en fonction de vos besoins. C'est-à-dire que si vous avez besoin d'un serveur web, vous pouvez mettre un container **HTTP** (**Apache** ou **Nginx**), un container base de données (**MySQL**, **PostgreSQL** ou **Mongo**), un autre container **Node** v.XX (avec un mapping vers le dossier de code source afin que **Node** puisse interprêter votre code).

Dans ce cas, votre code source sera prêt à bouger d'une machine à l'autre très facilement. De plus, les containers eux-mêmes peuvent être déployés en groupe via des outils comme [Docker-Compose](https://github.com/docker/compose).

#### Automatiser ses déploiements 🤖

Aujourd'hui on a des outils comme [Jenkins](https://www.jenkins.io/) qui sert à gérer et orchestrer ce qu'il se passe sur votre serveur. **Jenkins** vous offrira une interface sur laquelle créer vos **workflow**. Remarquez que ce service aussi peut être déployé via un container **Docker**, si vous souhaitez gagner du temps.

Par exemple : 
- Un **workflow** déploiement qui appelle chacun des scripts vu ci-dessus.
- Un autre **workflow** mise à jour qui n'appelle qu'une partie des scripts pour mettre à jour le code sources et les dépendances puis relancer les services

**Jenkins** distribue également beaucoup de plugins pour ajouter des fonctionnalités, comme : appeller certains scripts, envoyer des notifications, etc...

De plus **Jenkins** est un serveur web, celà implique qu'il est possible de mettre en place des endpoints qui vont déclencher des workflows. Cela vous permet entre-autre de mettre en place des **webhooks** !

Concrètement, les **webhooks** sont des URLs appelées par certains services comme **Github** (mais pas que) qui permettent de faire suite à des événements spécifiques au service. Dans notre cas on pourrait mettre très rapidement en place notre **CI/CD** : **Continuous Integration, Continuous Delivery**.

Autrement dit, on peut tout simplement, depuis Github demander à Jenkins de déployer notre code sur le serveur en fonction de certains événements (comme les **push** sur la **branche master**).

#### Sécurisez vos déploiements 🔒

Jenkins est totalement exposé au web depuis le port que vous aurez choisi, il convient de mettre un peu de sécurité en place pour éviter le pire.

Essayez de mettre en place un moyen d'authentification (au moins un **Basic Token**) sur vos **webhook**. 

Pour vos projets gitbub en repository privés, je vous recommande fortement, l'utilisation de [clés de déploiement](https://docs.github.com/en/enterprise-server@3.4/authentication/keeping-your-account-and-data-secure/reviewing-your-deploy-keys) afin de ne jamais exposer vos identifiants / mot de passe.

Sur vos **workflow**, mettez toujours des étapes de tests, comme le lancement de vos Tests Unitaires. Et si les tests sont au rouge, arrêtez le déploiement, pour d'éviter de casser votre production.

Mettre en place un [fail2ban](https://doc.ubuntu-fr.org/fail2ban) afin de limiter la casse au niveau des tentative de brutforce par les bots.

Mettre en place un [ufw](https://doc.ubuntu-fr.org/ufw) firewall avec des règles de qu'est-ce que l'on ouvre ou pas comme ports (attention au port SSH 22, vous risquez de perdre totalement la connexion vers votre serveur si vous vous y prenez mal).

En général je désactive totalement les connexions **SSH** qui ne sont pas en **authorized_keys** et je whiteliste uniquement ma clé publique (avec backup des clés sur USB au cas où).

Voici quelques lignes de ma config ssh : 

```
 PasswordAuthentication no
 PubkeyAuthentication yes
 UsePAM no
 MaxAuthTries 2

```

### Surveiller son serveur 📈

La dernière étape une fois que votre site est en ligne, consiste à voir ce qu'il s'y passe. Pour cela, il faut mettre en place des logs. Sans chercher à faire trop compliqué j'ai tendance à demander à mes services de rediriger tout sur **/var/log/syslog** puis je me mets en écoute dessus en cas de besoin.

Si vous voulez aller plus loin dans les logs, vous avez des outils comme **Sentry** et **Dynatrace**. Qui permettront notamment de vérifier la performance de vos applications, en matière de délais.

### Pour aller plus loin 🔍

C'est un vaste sujet que je continue d'étudier chaque jour, le déploiement et l'administration des machines est vraiment un domaine passionnant, plein de challenge (lorsqu'il faut faire avec de toutes petites ressources, réussir à trouver des optimisations, des hacks ou encore lorsque vous avez des distributions linux exotiques... c'est du vécu ! 😂).

Tout ce que l'on a vu ici ne sont que des approches. Il ne tient qu'à vous de les challenger, de les améliorer, de faire autrement, mais je vous invite à mettre en place le plus d'automatisation. 

Un déploiement maîtrisé, c'est beaucoup plus de sérénité pour les développeurs car on sait que l'on a la capacité de rollback rapidement en cas de problèmes.

On peut aller encore beaucoup plus loin dans l'automatisation de ses déploiements via des outils comme [Terraform](https://www.terraform.io/). Cela nécessite un peu de pratique et de la formation, mais comme à peu près tout, il faut bien commencer quelque part. 😅

**Et comme j'aime souvent le dire : le rythme de déploiement de votre projet est un peu le rythme cardiaque de votre projet**.

large_ian-battaglia-9drS5E_Rguc-unsplash.jpg

medium_ian-battaglia-9drS5E_Rguc-unsplash.jpg

small_ian-battaglia-9drS5E_Rguc-unsplash.jpg

thumbnail_ian-battaglia-9drS5E_Rguc-unsplash.jpg

ian-battaglia-9drS5E_Rguc-unsplash.jpg

Un des grands oubliés d'un développeur fullstack, c'est de pouvoir déployer. Très souvent, on vous dira qu'être un développeur fullstack ne signifie pas devoir se charger du déploiement et qu'il s'agit d'une compétence SysAdmin ou Ops. Cependant, lorsque vous faîtes vous même votre projet de A à Z, il faudra bien le déployer !

Passer de frontend à backend - le déploiement

## La maîtrise de vos données 👌

Un des pilier d'une application c'est bien la couche de données, d'ailleurs, je pense même que c'est la couche technique (non perçu par le client) la plus importante, et je vais vous expliquer pourquoi. 

**Les données sont les seuls éléments de votre application dont l'intégrité est un besoin capital et la disponibilité une préoccupation majeure.**

Pour le dire simplement, on peut changer la couche graphique (partie frontend) de votre application, on peut changer votre backend (remplacer les API par un nouveau framework, un nouveau langage), mais vos données doivent rester intactes et accessibles. 

Il faut que vos données soient sans cesse cohérentes et que l'accès au données soit contrôlé. Tant au niveau de la base elle même (user/password), mais aussi au niveau accès ressource. Un utilisateur peut modifier son compte utilisateur mais pas celui d'un autre. **Comprenez qu'il y a des mécaniques de vérification qui devront être pris en compte et surtout mis en place.**

Quels sont les points à maîtriser pour déployer notre base de données applicative sereinement ?

### Choisir sa base 🤔

Il y existe plusieurs types de bases de données que vous pouvez déployer pour faire votre application. Chacun avec ses avantages et ses inconvénients : 
- les bases **SQL** : efficace pour le calcul et l'association de données inter-table (en gros je peux facilement associer un produit à un utilisateur etc car ces bases de données sont dites relationnelles).
- les bases **NoSQL** : qui signifie Not Only SQL et pas No SQL... Qui sont des bases orientés document (où il est plus difficile de faire des associations inter-données, mais qui permettent d'avoir une structure plus malléable).

Une des grosses différences entre ces deux types de bases, c'est que les bases **SQL** ont besoin d'avoir une structure bien définie : un champs possède tel nom et est de tel type (définition des colonnes). **SQL est une base pratique pour un projet mature en terme de besoin** : 
- vous savez quelle donnée vous souhaitez enregistrer, 
- vous savez pourquoi vous stockez ces informations 
- et quels sont les liens entre ces données.

Alors que la base de donnée documents vous permet d'être beaucoup plus souple : vous pouvez faire évoluer la source de données quand bon vous semble et ajouter des champs à la volée. Il est même possible que dans une source de même type, les documents aient des clés différentes. **Ce type de base est parfait dans une phase de rodage du modèle de donnée et de structure**. De même, sa performance fait que vous pourrez la garder indéfiniment tant que votre structure est optimisée.

Par exemple, en NoSQL, il est possible d'avoir une source de données Produits, et un produit aurait la clé "size" et un autre produit aurait la clé "quantity" sans la clé size... Je ne recommande pas cette pratique qui crée beaucoup de confusion à la lecture des données et vous force à implémenter beaucoup de vérifications.

Concernant les technologies à votre disposition, pour les bases **SQL**, les plus utilisés sont les bases [MySQL](https://www.mysql.com/) et [PostgreSQL](https://www.postgresql.org/). Les deux fonctionnent très bien et possèdent une communauté très active si vous cherchez de la documentation.

J'ai une tendance particulière à aller vers du MySQL pour des projets simples et du PostgreSQL pour des projets plus complexes avec beaucoup plus de données (> 1go).

Pour les bases **NoSQL**, les plus connus sont [MongoDB](https://www.mongodb.com/) et les bases [Neo4j](https://neo4j.com/). J'adore **MongoDB**, c'est un type de base que j'utilise souvent pour prototyper rapidement. 

Pour les bases **Neo4j**, je dois admettre que je n'y connais pas grand chose car je ne m'en suis jamais servi. Mais le concept est le suivant : essayer de garder les avantages des bases documents en mettant l'accent sur les relations inter-données. Ce qui nous donne **une base de données orienté graph** (pour faire le lien entre les données). Et ici l'objectif est clair, essayer de faire des bases documents avec les avantages des bases relationnels. Cependant la syntaxe est particulière et il vous faudra apprendre le **Cypher**, un graph query langage qui vous permet de faire des requêtes.

---

Le sujet de la base de données est tellement un sujet critique que de nombreux acteurs ont cherché à résoudre cette problématique afin de vous apporter des solutions simples. 

**Google** déploie plusieurs services de données simples en SaaS : 
- **Firebase** : une base documents simple avec une couche socket pour propager des événements
- **Firestore** : comme firebase mais avec des services en plus comme les notifications, le machine learning, etc...
- **Datastore** : commence à être abandonné pour firestore (les API sont dores et déjà les mêmes)
- **Bigtable** : base de données NoSQL pour des grosses opérations (calculs de stats, analyse, etc...)

**Amazon** aussi met en place plusieurs services : 
- **DynamoDB** : une base documents peu coûteuse et pratique
- **DocumentDB** : une base de données MongoDB-like (les prix commencent à 190$ environ par mois)
- **RDS** : une base de données SQL (MariaDB ou PostgreSQL)

Il existe bien d'autres offres en SaaS pour les bases de données, mais je ne vais pas faire une liste exhaustive des possibilités. Je vous ai listé ici les plus utilisés et les plus documentés.

Tous ces services sont managés pour vous, cela signifie que vous n'aurez pas à les tenir à jour en terme de version, de sécurité, d'intrusion, etc... Les providers s'occupent de tout et c'est là l'intérêt. Mais vous l'aurez compris, il s'agit d'un service donc cela vous demandera de mettre la main au portefeuille.

### Utiliser un ORM ⚒️

Si vous décidez de partir sur une base déployée par vos soin : SQL ou base document. Vous allez devoir gérer le service, les montées en version, la maintenance etc... Mais pas que !

Côté code, il faut réussir à vous y connecter. Et pour ce faire, il y a des librairies qui gèrent pour vous, de manière simple, les sockets et l'accès aux données. 

Ces librairies s'appellent les ORM : Object-Relational Mapping, c'est à dire un objet qui est lié à la donnée depuis le code. Soit une visualisation simplifiée de la donnée afin de la manipuler plus facilement.

Pour les bases SQL, les ORM sont légions : 
- **Knex.js**
- **Prisma**
- **Sequelize**

Ces ORM sont très bien documentés et tout ce dont vous avez besoin est à votre disposition. Comment créer un objet, comment écrire, comment lire, comment mettre à jour et comment supprimer... Tout y est !

Pour les bases de données NoSQL, notamment MongoDB :
- **Mongoose** : l'ORM le plus connu
- **Prisma** : avec une syntaxe très proche du modèle SQL

L'**ORM** vous garantie d'accéder à la donnée de manière efficace, sans duplication de code et de cadrer votre utilisation par les conventions. Dans une équipe, cela vous permettra d'avoir un code source organisé et de pouvoir travailler en toute cohésion grâce à une méthodologie commune.

D'une certaine façon, les bases de données **SaaS** déployés par les providers sont eux-aussi livrés avec des librairies en guise d'**ORM**. Cela facilitera son intégration et soyez sûr qu'ils aient mis le paquet sur la documentation puisqu'ils souhaite une adoption massive du marché. Ce qui signifie que la qualité du service et de la documentation seront au rendez-vous.

### Les points d'attention ⚠️

Après avoir vu les types de base de données et les **ORM**, il est temps de parler de ce sûr quoi vous devez être vigilent pour vous assurer le maximum de confort et de fiabilité en matière de données.

#### La performance des bases de données ⚡️

Premièrement je vais aborder le sujet de la performance lorsque l'on fait un choix de base de données. 

On s'attend à :
- des réponses rapides
- pouvoir faire des tris rapidement
- pouvoir filtrer les résultats

La performance est souvent un des critères mis en avant pour le choix d'une base de données. Mais sachez que la performance ne dépend pas que de la technologie mais aussi des performances machines. 

Une machine avec un SSD, beaucoup de RAM et beaucoup de cores sera forcément plus performante qu'une demi-VM avec une ram ponctionnée et 50% du temps CPU... On va dire que jusque là tout est logique.

**Mais il faut savoir que la performance s'entretient** ! Il n'est pas rare de voir les performances d'un système de base de données décliner dans le temps. 

Pourquoi ? 

Tout simplement parce qu'il y a plus de données à traiter...

Que peut-on faire dans cette situation ? 

##### Les indexes 🔍

Y-penser dès le départ en anticipant sur les tables qui vont grossir rapidement, les colonnes clés sur lesquels filtrer, etc... Et mettre en place des **indexes**. Les indexes vont jouer comme des poids dans la structure de vos données. En gros, ils vont expliquer au moteur de base de données qu'est-ce qui est suffisamment important pour que la base optimise la distribution de cette donnée. 

Pour vous illustrer un peu cela : 

Lorsque l'on crée une table Users, votre clé primaire ID est indexée par défaut. Autrement dit, lorsque vous recherchez un User, en mettant une condition sur l'ID vous irez beaucoup plus vite que si vous le cherchez par son email.

Maintenant, le système d'indexation n'est pas exclusivement dédié à la clé primaire, vous pouvez très bien indexer n'importe quelle donnée de votre table. Car vous savez que vous vous servirez de tel champs pour vos requêtes. **Et cette optimisation prendra certes un peu plus d'espace sur le disque, mais vous sauvera la mise quand vous aurez atteint une taille critique de base**.

De plus, le système d'indexes n'est pas réservé aux bases SQL. Vous pouvez tout aussi bien mettre des indexes sur des bases NoSQL. Il faut garder en tête que c'est important et y penser en amont.

##### Le nettoyage des bases 🧹️

Par ailleurs, il y a aussi à travail à faire quant au nettoyage des données. Lorsqu'un projet va durer dans le temps et risque de fortement grossir, il faut mettre en place des règles de nettoyage de votre base de données.

En **PostgreSQL** vous avez un système de **VACCUM** qui va surtout être utile pour la partie disque. Mais entre-nous, il y a moyen d'optimiser tout type de base à condition d'avoir une méthode et de faire des choix.

Sur d'anciens projets, on avait pris l'habitude de garder 1 à 2 ans d'historique en base dite "active" et de basculer le reste en base dite "d'archive". Cela permet de maintenir le volume de données dans une tranche qui fait que le temps de traitement sera impacté dans une moindre mesure. 

Après, il faut que le projet s'y prête, mais globalement on a toujours des méthodes qui permettent d'adapter la mise en place de ce genre de bascule. Typiquement, vous pouvez décider que pour les années à archiver, on ne garde en base que les minimum, maximum et moyenne pour certaines métriques, etc...

Je vous le disais, il s'agit de choix, dans le but de garder un applicatif fluide lorsqu'il exécute des requêtes.

#### Votre trousse de premier secours 🚑

**Il est impératif de vous munir d'outils pour des interventions rapides en cas d'urgence**. Il vous faut constituer ce que j'appelle la trousse de secours de votre base de données.

Autrement dit, je me prépare souvent une liste de scripts prêt à être exécutés via un CLI (terminal) à tout moment pour me sauver la mise en cas de besoin.

En général il faut que ce genre d'opération mette moins d'une minute à lancer (l'exécution, c'est autre chose...). 

Voici la liste de ce que je garde sous le coude en cas de besoin : 

- Un script de déploiement de la base
- Un script de backup de votre database
- Un script de restauration votre base 
- Un script pour créer vos utilisateurs 
- Un script pour mettre à jour un mot de passe utilisateur
- Un script qui permet de feed (mettre en base les données essentiels au bon fonctionnement de votre projet)

Voilà je pense qu'on a fait un peu le tour pour la partie base de données. Comme vous pouvez le voir il y a de nombreux sujets à aborder, et il en reste encore tellement ! 

Je peux vous rassurer, j'ai commencé de 0 moi aussi, et ces informations deviendront totalement logiques et simples pour vous aussi dans très peu de temps. 
Il suffit de s'y mettre !

Dans un prochain article on parlera des déploiements, restez connectés ! 😉

large_tobias-fischer-PkbZahEG2Ng-unsplash.jpg

medium_tobias-fischer-PkbZahEG2Ng-unsplash.jpg

small_tobias-fischer-PkbZahEG2Ng-unsplash.jpg

thumbnail_tobias-fischer-PkbZahEG2Ng-unsplash.jpg

tobias-fischer-PkbZahEG2Ng-unsplash.jpg

Dans notre démarche pour passer de développeur frontend à développeur backend, les bases de données sont un point de passage obligatoire pour devenir fullstack. Quels sont les points essentiels à maîtriser pour surmonter aisément cette étape ?

Découvrez tous nos articles de la catégorie Dev - page 4 sur 6