## Mon petit serveur

Comme à mon habitude, je travaille sur des projets persos et met en ligne mes tests sur des serveurs **VPS**. Dernièrement j'ai un de mes serveurs qui s'est fait hacké par un soit disant "rambler" qui me demandait 0.2 BTC soit 4000€ au moment où je vous parle pour récupérer mes données. 

Bien entendu, il s'agissait d'un serveur de test donc autant vous dire qu'il peut s'asseoir dessus encore bien longtemps, avant de recevoir quoique ce soit de ma part. Quoiqu'il en soit j'ai tout de même réalisé qu'il y avait un problème quelque part. 

Mais où ?

### Ce que je vérifie par défaut sur mes serveurs

A chaque serveur que je monte, je prends le soin de mettre en place **ufw** (le firewall) et un **fail2ban** (pour empêcher le brut force). Et jusque là tout s'est toujours bien passé. Pour tout vous dire, je désactive toujours la connexion distante par mot de passe sur **SSH** et j'ai une liste de clé **SSH** autorisés que je garde précieusement (backupé au cas où). 

Jusque là j'ai eu des serveurs qui ont tenu bon. Je vois des logs passer, sur des dizaines de millier d'IP que j'identifie être une tentative de brut force de la part d'un bot net. Mais ils ne sont pas prêt d'y arriver et ça fait 5 ans que ça dure... 

### Trouver la faille

Le jour où je me suis fait hacké ce serveur, ils ont réussi à accéder à ma base **MySQL** et ont tout extrait avant de supprimer et de laisser un message avec les instructions pour la récupération. Très bien mais comment ont-ils fait ?

J'étais pourtant persuadé que mon ufw était configuré en deny by default. Ce qui veut dire que le firewall rejette systématiquement tout ce qui rentre, à part ce que j'ai ajouté en liste comme étant autorisé. Par exemple certains ports, comme SSH, certains protocoles comme le Web avec Nginx, etc...

Me serais-je loupé cette fois-ci ? Aurais-je oublié de le faire ? 

Je vérifie... Et la réponse est **NON** !

Je n'ai absolument rien oublié, et tout était bien configuré. 

Donc il ne me reste plus qu'à tester quelque chose : une connexion distante vers mon serveur **MySQL**.

Résultat : Ca passe ! J'arrive à me connecter ! WTF ? 😱

Je suis sans voix, qu'est-ce qui a bien pu se passer pour que **ufw** ne fasse pas son boulot ?

Je reprends mes investigations, le service défaillant est **MySQL**. 

Il a été déployé comment ? Je suis passé par un **Docker**. 

Certes, j'ai fait l'erreur de laisser un mot de passe bidon, mais jusque là j'étais persuadé d'être derrière un intranet. Bon... Ceci n'est plus un problème.

Mais pour ce qui est de la vraie question : Qu'est-ce que **Docker** est en train de me faire là ? 🧐

Et ben la réponse est : vraiment n'importe quoi ! **Docker** crée ses propres règles firewall, donc il bypass **ufw** ! 

Pour régler le problème il faut configurer un fichier **/etc/docker/daemon.json** et ajouter une ligne :


```
{"iptables":false}
```

**Incroyable !** 🤔

Mais maintenant, j'en rigole, je me dis qu'il vaut mieux que ce soit un serveur de test qui sert à rien. Ca aurait pu être beaucoup plus grave, et ça veut dire que ça l'est pour beaucoup de gens qui ne savent pas que **Docker** et **ufw** ne font pas bon ménage, par défaut.

### Conclusion

Faîtes bien attention si vous aussi vous utilisez ces services, vous risquez d'avoir bien des surprises dans le futur. Mais cette expérience m'a fait réaliser qu'il vaut mieux ne jamais faire confiance lorsque l'on monte une machine et que l'on teste absolument tout pour vérifié le niveau de sécurité.

Content d'avoir appris quelque chose. 😄

large_clint-patterson-dYEuFB8KQJk-unsplash.jpg

medium_clint-patterson-dYEuFB8KQJk-unsplash.jpg

small_clint-patterson-dYEuFB8KQJk-unsplash.jpg

thumbnail_clint-patterson-dYEuFB8KQJk-unsplash.jpg

clint-patterson-dYEuFB8KQJk-unsplash.jpg

Ce genre de problèmes arrive à tout le monde et je ne serai pas le dernier. Lorsque l'on monte son serveur, il y a souvent des petites failles qu'il faut colmater pour éviter de se faire pirater. C'est ce que j'ai fait, pourtant des hackers sont passés, je vous explique comment il s'y sont pris.

Comment des hackers ont essayé de me ransomware

## Pourquoi faire de la sécurité informatique ?

Quels sont les risques encourus si je ne fait pas attention à mon matériel et mes logiciels ? Car oui, la sécurité informatique c'est un tout, et ça commence déjà par l'accès au matériel. Donc les locaux jouent déjà un rôle dans tout ça. 

Les devices contiennent souvent des code d'accès que vous sauvegardez dans vos navigateurs pour éviter d'avoir à les entrer à chaque fois. Pour beaucoup de gens, l'accès à leur machine, signifie immédiatement, l'accès à leur données sensibles.

### L'accès aux informations des particuliers

Tout d'abord en tant que particulier, faire attention à l'accès à nos devices, ça signifie mettre une barrière entre nos données et d'autres personnes mal intentionnées. Beaucoup de gens pourraient dire, oui mais je n'ai rien à cacher... Si si, je vous assure que si ! Votre carte bancaire par exemple, vous aurez tout intérêt à le cacher ! Votre adresse, vos itinéraires quotidiens, vos numéros de téléphone, tout peut servir et jouer contre vous. 

Il a été plusieurs fois prouvé que l'accès à des données vraisemblablement anodines ont causés énormément de tord à plusieurs personnes. Votre numéro de téléphone peut être utilisé pour vous spammer de SMS, d'appels surtaxés etc... Votre adresse peut servir pour vous prospecter, ou encore à savoir où venir régler des comptes si vous vous mettez à dos les mauvaises personnes. Votre profession peut servir à faire du démarchage ciblé, parfois même ce que l'on appelle le social engineering (une forme de hacking, basé sur l'humain).  Bruno Gaccio, qui travaillait aux guignols de l'info parlait d'une tentative d'assassinat sur sa personne basée sur son itinéraire personnel quotidien. 

Parfois, l'accès aux données des particuliers permettent aux hackers de remonter leur hack jusqu'au lieu de profession de ces derniers. Une faille d'un particulier devient alors un problème d'entreprise, donc il faut rester vigilant et se former à chaque instant !

### L'accès aux données des pro

De nombreuses fois, le fait de savoir qu'une personne était la secrétaire de direction d'une entreprise a permis à des hackers d'utiliser ses accès pour lui faire exécuter des ordres de virement. La personne a reçu un email de la part de son patron, enfin, en apparence, mais son manque de connaissance en informatique et de clairvoyance au moment où c'est arrivé ne lui a pas permis de voir la nuance dans le nom de domaine de l'entreprise, enregistré ailleurs que sur le traditionnel ".fr". 

Sur des serveurs, l'accès aux données peut compromettre énormément de gens. Le hack d'un site e-commerce peut diffuser à grande échelle des code de carte bancaire, nom et prénom, de tous les clients. Ceci est déjà arrivé ! Et les professionnels doivent prendre encore plus de mesure pour stocker ce genre d'informations compromettantes. Une certification est demandée pour être habilité à le faire, dans le cas contraire il faut passer par des services qui possèdent cette certification. La CNIL (organisme en charge des bonnes pratiques concernant les données informatiques) veille à ce que des règles soient respectées par les acteurs du web.

De même, sur des serveurs, il peut arriver que si vous stocker vos machines dans des datacenter. Les failles logiciels provenant de vos machines peuvent vous coûter cher. Etant donnée que vous êtes responsable du maintient et de la mise à jour des machines en matière de faille logicielle, si jamais vos machines donnent l'accès au datacenter à cause d'une faille, en tant qu'entreprise vous êtes passible de poursuites.

Il y a tellement à perdre dans ce genre de situation, que désormais les grands groupes etc accordent un budget dédié à la sécurité. De même pour ne prendre aucun risque sur les projets, je recommande souvent aux développeurs de partir de librairies créés from scratch par les équipes pour éviter les failles dans les paquets téléchargés. 

En outre, une entreprise si elle s'est faite hackée ou si elle a la moindre suspicion d'un hack sur ses serveurs, a l'obligation de le déclarer. C'est une loi qui date de plusieurs années maintenant, pourtant on apprend parfois que les sociétés font l'autruche et se taisent pendant des années. En 2012, on apprenait que Coca Cola s'est fait hacké par les chinois, lors de sa tentative d’acquisition de China Huiyuan Juice Group, et ce hack remontait à 2009...

### Comment mieux se protéger

En tant que particulier, il faut prendre le temps d'apprendre, de comprendre ce que l'on fait pour éviter tout problème. De plus, pour éviter le hack, il faut souvent éviter d'avoir un comportement qui nous fait prendre des risques. Les gens qui cherchent absolument à pirater du contenu sont les premiers touchés par ce genre de problème. En voulant absolument télécharger la dernière série à la mode, ils se font eux même contaminer leur machines. 

Par ailleurs, le hack arrive aussi dans des cas de téléphone ou ordinateur prêté aux enfants. Très souvent, il s'agit d'une porte d'entrée pour des gens mal intentionnées. Les enfants qui voient "nouveau jeu gratuit, clique ici"... C'est arrivé plus d'une fois et dans quasiment toutes les familles. Parfois on oublie que dans ces appareils, il y a un accès vers nos compte en banque, nos documents d'identité... Je ne dis pas qu'il ne faut plus prêter d'appareils aux enfants, mais surtout qu'il faut prendre le temps de surveiller ce qu'ils en font, et de leur inculquer les bons réflexes.

En tant qu'entreprise, je vous conseille un budget dédié à la sécurité informatique, tant les événements des dernières années ont changé la dimension du numérique. L'apparition des crypto locker et autres ransomware qui servent à mettre les boîtes à la merci des pirates ont démontré que très peu de sociétés prenaient cette menace au sérieux. 

### Parfois la menace vient de l'intérieur

Dans de nombreuses sociétés, on a pu trouver des éléments qui montre que les failles venaient de l'intérieur. Et que parfois ces failles étaient volontairement ouvertes ! De même, on a pu trouver énormément de cas où, des employés ont essayé de tirer profit de leur entreprise. En exploitant des machines pour miner de la crypto, en prenant des documents et demandant des rançons, etc... 

Je pense qu'il faut revoir les stratégie d'habilitations et d'accès aux fichiers dans une entreprise pour ne pas permettre à n'importe qui de faire n'importe quoi.

### Parfois même la menace vient d'une organisation corrompue

Dans certains pays où règne la corruption, il arrive même que des gens glissent des documents corrompus dans vos affaires pour vous faire porter le chapeau et vous mettre en prison. Le but n'est pas de vous emprisonner pour rien, si vous êtes quelqu'un d'influent, un politicien etc, vous risquez de vous retrouver hors course, car enfermé...

01net a [écrit sur le sujet](https://www.01net.com/actualites/certains-policiers-sont-passes-maitres-en-fabrication-de-fausses-preuves-informatiques.html) et montre à quel point des organismes officiels peuvent cacher des pirates.

### Conclusion

Il y a quelques temps, on apprenait que les failles peuvent aussi venir des appareils eux même. Certains fabriquant laissent volontairement ce que l'on appelle une backdoor (c'est ce que D. Trump reprochait à Huawei), d'autres le font involontairement (enfin c'est ce qu'ils disent). Intel et AMD ont connu ce genre de problèmes sur leur CPU et ont du mettre en place des mises à jour pour combler ces failles.

La meilleure arme contre le piratage, c'est d'être informé, des méthodes car même si elles évoluent toujours, il est plus probable que vous ne soyez pas le premier visé lorsque cela arrive. De même, il faut comprendre ce qui permet le hack, et ce qu'il y a à pirater pour prendre des mesures. Pour les société, il faut investir pour sa sécurité. Cela parait fou de devoir faire ça, mais c'est surtout beaucoup de bon sens. 



nahel-abdul-hadi-flha0KwRrRc-unsplash.jpg

large_nahel-abdul-hadi-flha0KwRrRc-unsplash.jpg

medium_nahel-abdul-hadi-flha0KwRrRc-unsplash.jpg

small_nahel-abdul-hadi-flha0KwRrRc-unsplash.jpg

thumbnail_nahel-abdul-hadi-flha0KwRrRc-unsplash.jpg

Cela fait un moment que les gens commencent à prendre conscience de la sécurité informatique et des enjeux autour de cela. L'informatique a fait avancer le monde dans de nombreux domaine, mais peut aussi être une menace sur d'autres plans, du moins, tant que l'on n'adopte pas de bonnes pratiques avec nos machines.

La sécurité informatique à tout prix

Plusieurs fois, je me suis posé ces questions :

- Comment Dailymotion a perdu face à Youtube ?
- Comment Deezer a perdu face à Spotify ?
- Comment Kodak a perdu face au numérique ?
- Comment IBM a perdu la course aux PC ?
- Comment Nokia a perdu face au smartphone ?

Comme le chef Michel Dumas 👨‍🍳, j'ai tourné et retourné ces questions dans ma tête de la manière suivante : 

- Est-ce que leur chute est forcément dû à leur concurrence ?
- Comment se fait-il qu'une entreprise leader en difficulté, n'a pas trouvé les ressources pour se retourner ?
- Comment conserver une position de leader ?

Tout ceci, bien sûr n'est que théorie et supposition. Bien sûr, je me suis pas mal documenté sur le sujet afin d'essayer d'y répondre clairement. Nous allons essayer d'analyser chacun des cas présentés.

### Un phénomène courant

D'après ce que j'ai pu constater, il n'est pas rare qu'une société leader dans le passé, disparaisse du jour au lendemain. Et dans 90% des cas, il s'agit d'une mauvaise décision prise en interne (on va dire que pour les 10% restants, il s'agit d'une pénurie de matière première ou d'un phénomène imprévisible, comme une catastrophe, décision externe, etc...).

Cela parait tout de même incroyable, qu'une mauvaise décision, un virage mal négocié ait emmené ces sociétés droit dans le mur. Mais c'est pourtant vrai !

#### La chute de Kodak

Chez Kodak, en 1976, Steve Sasson présente un modèle d'appareil photo capable de diffuser sur la télévision s'est fait rembarrer par le PDG avec une remarque dédaigneuse : "Pourquoi les gens voudraient visionner leur photo sur une télévision ?".

Mon analyse m'emmène à penser qu'il a commis plusieurs erreurs :
- Sa première erreur a été de penser à la place du marché, c'est à dire qu'il a préféré deviner, que cela ne plairait pas plutôt que de tester son produit. Cela relève d'un problème d'égo, après avoir eu raison un certain nombre de fois, on une tendance à penser que l'on connait déjà les attentes du marché. 
- Deuxièmement, il n'a pas vu plus loin que ce qui lui a été présenté. Son jugement s'est arrêté à ce qu'il a vu sans dépasser le cadre et voir les possibilités derrière. Car, rappelons-le, ils auraient très bien pu s'appuyer sur cette technologie pour être en avance sur la photo numérique. 

Et Kodak, a justement raté le coche du numérique, c'est tout de même dommage...

#### La chute de Dailymotion 

Dailymotion ou Daily pour les intimes, a longtemps été un adversaire à jeu égal avec Youtube, du moins, dans les premières années. Mais les deux sociétés ont pris des trajectoires totalement différentes suite au rachat de Youtube par Google. 

Que s'est-il passé ? 

D'un côté, vous avez un modèle américain qui conçoit l'investissement massif et qui injecte via Google des fonds colossaux dans la machine Youtube. De l'autre côté vous avez un modèle français où il y a moins d'argent sur la table car moins de moyen, parce que moins d'audience. Bien sûr, Dailymotion diffusait sur plusieurs pays, mais il faut l'avouer, cela marchait surtout sur notre territoire.

Ce que je pense :

L'Etat français a bridé le développement de la plateforme **Dailymotion**. Plusieurs fois, l'Etat s'est prononcé, parfois même en allant jusqu'à mettre son veto. Notamment sur la possibilité de rachat partiel par Yahoo... 

Ce qu'il fallait à Dailymotion dans ces moments là, c'était des fonds ! Rien d'autre que du cash pour nourrir la machine en R & D. Donc la stratégie pro-territoire, franco-français, et les enjeux de l'indépendance tech, je comprends, mais cela a eu un effet pire que si nous avions vendu partiellement la société. 

Concernant le montant du rachat, aucun organisme en France n'était prêt à le mettre sur la table, et les avancés technologiques de Dailymotion, de mon point de vue n'étaient pas aussi incroyable en matière d'innovation, pour justifier l'arrêt de la transaction. 

A titre de comparaison, **Fabrice Bellard (FFMPEG)**, **Jean Baptiste Kempf (VLC)** font bien mieux en matière d'innovation, mais personne ne parle de leur travail, à leur juste valeur j'entends. Et ces derniers ont opté pour l'open source, alors que ce qu'il font a littéralement révolutionné la tech... 

Des géants comme **Google** se servent de leur algorithmes sur Youtube, mais ici, personne n'est venu interdire ces champions d'ouvrir leur code source. C'est pourquoi, je ne comprends pas le positionnement des politiques, qui me parait souvent à contre-courant. 

Pendant son heure de gloire, le talent de Daily, c'était son acquisition et sa rétention !

#### La chute de Deezer

Pour Deezer, il y a un double problème. Je sais que ce que je vais dire ne va pas arranger son introduction en bourse même si je lui souhaite tout le meilleur pour la suite, mais, après avoir été largement leader sur le marché français. Deezer connait aujourd'hui un très gros recul, il passe de 51% à 30% en 6 ans. Sans compter le fait qu'il n'a toujours pas réussi à s'imposer à l'international. Avec 2% de couverture aujourd'hui, face au géant suédois Spotify qui prend 31% du marché mondial à lui seul. 

Je n'ai pas de formule miracle, mais je dois juste constater d'un point de vue totalement extérieur et sans avoir connaissance des tenants et aboutissants de ce milieu, que la stratégie de Spotify a toujours été de viser le marché international. Et cette stratégie a payé car ils se sont largement imposés, en mettant dès le début la langue de l'application en anglais.

Chez Spotify, ils avaient déjà pensé le produit pour le monde entier, alors qu'au tout début Deezer avait pensé le produit pour les français sur un modèle qui sera décliné ensuite. Peut-être que l'on peut se trouver des excuses comme : "c'est plus simple pour les suédois, de par leur culture, de faire un produit en anglais". Un phénomène que j'ai observé, c'est que souvent le marché français suit la tendance mondiale et que l'on reste rarement sur nos projets nationaux. Pour preuve : 
- Le Trombi s'est fait terrassé par Facebook
- Le minitel s'est fait engloutir par internet
- Priceminister (revendu à Rakuten depuis) est moins performant que Vinted 

Je n'ai pas de meilleure idée de comment cela aurait du se passer. Cependant, il reste un marché francophone mondial de 300 millions de personnes, donc la part de gâteau reste quand même intéressante. Mais il ne faut pas oublier que le leader mondial pourra toujours récupérer cette part dans le futur, étant donné qu'il dégage tout de même plus de marge avec un marché plus conséquent. 

#### Les erreurs d'IBM

IBM a longtemps été leader du marché informatique et même plus ! Pendant longtemps, l'action IBM a culminé tout en haut du marché américain. Et dans l'esprit de nombreux investisseurs, il s'agissait là d'une valeur sûre. Ce qui a été vrai pendant très longtemps, le déclin en bourse d'IBM n'étant que tout récent (à partir de 2014). 

IBM reste un des pilier de l'informatique moderne, ce n'est pas parce que, comparé aux GAFAM/FAANG, cette société est plus discrète que pour autant, elle ne fait rien. Elle reste dans de nombreux domaines telles que l'IA etc, une référence en la matière. C'est à elle qu'on doit Deep Blue qui a vaincu G. Kasparov aux échecs. Et même en ce moment, laissez moi vous dire que Google n'est pas le seul à préparer un ordinateur quantique ultra puissant. 

Cependant, malgré toutes ces avances IBM aurait pu être encore plus gros que ce qu'il est actuellement. Dans les années 80, lorsqu'IBM préparait son ordinateur personnel, la société a fourni beaucoup d'effort sur la partie assemblage du matériel, mais avait sous estimé l'importance de la partie logicielle. Ils ont ainsi utilisé un système Microsoft, propulsant cette société vers les sommets. 

C'est grâce à ce marché que Microsoft est devenu le géant que l'on connait aujourd'hui. Effectivement, les deux sociétés étaient sur des marchés différents, mais dans l'IT céder une part de marché peut s'avérer fatal, si la croissance de l'autre société dépasse la première. C'est face à ce genre d'opportunité qu'il faut réussir à avoir la vision nécessaire qui permet d'identifier une fusion acquisition stratégique pour l'entreprise (ce que fait avec brio des gens comme Bernard Arnault).

#### La chute de Nokia

Pendant longtemps, Nokia a été dominé le marché des téléphones portables avec son produit phare le 3310. Adopté par tous les jeunes pour ses jeux, sa capacité à créer des sonneries etc... Bien avant les smartphones, Nokia était leader de son marché.

Nokia avait des produits pour les jeunes, les professionnels, leur gammes pouvaient plaire à tout le monde. La firme finlandaise brillait par sa présence et ses produits offraient bien plus qu'un simple téléphone cellulaire standard qui, initialement, ne permettait que de passer des appels. La société avait innové pour prendre le marché et en 5 ans seulement, son destin bascule...

Rendez-vous compte, avant sa chute Nokia détenait à lui seul près de la moitié du marché mondial. Plusieurs analyses montrent que Nokia était devenu arrogant et pensait savoir ce qu'il fallait au marché. Lors de l'explosion des smartphone, la réelle révolution se basait alors sur la partie logicielle, Nokia continuait à se concentrer uniquement sur la partie matérielle. C'est à ce moment qu'il se sont fait dépasser par tous les autres acteurs Apple, Samsung, etc. Nokia se refusait d'abandonner son système Symbian, pourtant c'est ce dernier qui causa sa perte. L'ironie dans tout ça, c'est que Nokia essayait de ne pas reproduire les erreurs d'IBM et d'avoir la maîtrise de tout son produit. Les internes, quant à eux, parlent d'un patron qui voulait décider de tout. 

Je pense que sa position de leader a créé à la fois une peur de perdre cette position et en même temps une arrogance qui laisse penser que l'on sait ce qu'il faut à un marché. D'où la tendance à ignorer le besoin client et ne pas faire le deuil de ses échecs quitte à plonger avec eux.

### Conclusion

Au-delà de tous ces cas, et de ces destins tragiques et talents gâchés, il y a souvent une mauvaise décision, une décision interne (Kodak, IBM, Nokia...), externe (Dailymotion). Souvent, ces décisions ont été le fruit de l'égo. 

Un égo démesuré : 
- de vouloir avoir raison plutôt que de vouloir gagner
- de penser savoir ce qu'il faut, plutôt que de laisser le client décider
- de vouloir préserver une propriété intellectuelle sur un territoire mais sans proposer une solution alternative (injection de fonds au moins équivalente)

Jeff Bezos, le PDG d'Amazon est souvent décrit comme odieux avec son personnel. Je ne dis pas qu'il faut l'être, à vrai dire, je ne sais même pas s'il l'est vraiment. Mais, une chose est sûr, il a toujours dit que sa priorité numéro 1 était sa clientèle. Cela lui a valu de créer l'une des boîte tech les plus puissantes du monde, aujourd'hui. 

Ce qui m'amène à penser, que les sociétés qui défendent leur place de leader, arrêtent souvent d'innover, de créer et de donner de la valeur aux clients, car ces derniers déploient toute leur énergie pour maintenir leur position. Pour ne pas perdre du terrain, elle ne tente plus rien de nouveau, fuit toute forme de risque, toute tentative différenciente et continue de proposer les mêmes produits. 

Et à partir du moment où le focus n'était plus le besoin client, mais la société elle même et sa survie, c'était le commencement de la fin pour elle. Cela donne le champs libre pour une jeune pousse qui n'a rien à perdre, de venir ravager un marché dormant.

En outre, il nous reste encore des pépites sur le territoire français : **BackMarket** est un bon exemple. Ce genre de sociétés devra relever des challenges encore plus compliqués que ce qu'il a connu jusqu'à présent. 

Cependant, je pense que des sociétés comme **Le Bon Coin**, se mettent en danger à être leader sur un territoire uniquement. Certes, ils ont l'avantage de connaître ce marché. En revanche, le jour où un leader étranger arrive et ravage le marché (comme c'est déjà le cas avec **Vinted** qui prend une partie de son marché grâce à la livraison incluse), ils ne pourront pas lutter. 

Et je pense que si on possède un business étendu sur plusieurs marchés comme **leboncoin** qui propose des bonnes affaires en tout genre, voitures et immobilier, il ne faut pas s'attendre à un concurrent qui viendra prendre tout ces marchés en même temps. Le risque réel, est que plusieurs acteurs, champions sur chacun de ces sous marché viennent prendre des parts du bon coin jusqu'à ce que tout soit plus intéressant ailleurs.

large_viktor-jakovlev-H0vuplqoX0c-unsplash.jpg

medium_viktor-jakovlev-H0vuplqoX0c-unsplash.jpg

small_viktor-jakovlev-H0vuplqoX0c-unsplash.jpg

thumbnail_viktor-jakovlev-H0vuplqoX0c-unsplash.jpg

viktor-jakovlev-H0vuplqoX0c-unsplash.jpg

La vie d'une société est à la fois une course et un marathon. Sur un marché compétitif, il faut réussir à conserver sa place de leader et cela semble être un exercice particulièrement difficile. Quels sont les points d'attention qui pourraient sauver une société de sa chute ?

Ces sociétés autrefois leader de leur marché

Cela fait quelques temps que je suis assez discret sur ce blog ! Et bien c'est tout simplement parce que j'ai changé de mission et que le départ m'engloutie un peu sous toute la machine d'onboarding. Mais sinon ça va ! Le projet est top et j'ai déjà hâte d'en découdre !

### Ce que je faisais avant

Pour ceux qui sont en contact avec moi sur **LinkedIn**, j'ai passé quelques mois sur un projet automobile. J'ai appris pas mal de choses et j'ai surtout rencontré des gens vraiment top ! Mes clauses de contrat m'empêchent de vous en dire plus sur ce que je faisais exactement mais je travaillais en tant que **Lead Dev Front** dans une équipe incroyable. C'était la première fois que je travaillais sur une stack **Typescript**, **Next**, **GraphQL**, bien que j'avais utilisé chacune de ces trois technologies de manière totalement indépendante par le passé.

### Ce que je fais maintenant

Alors je viens de passer dans une société un peu plus américaine je dirais 😅. Donc au niveau des process, meeting etc, on est en full anglais car les équipes sont répartis à travers le globe. Donc c'est top, ça fait une nouveauté pour moi de travailler de la sorte. Après pour le reste, on est sur des méthodos que l'on connait déjà. Sans trop rentrer dans les détails, mais voilà, ceci explique le fait que je poste un peu moins d'actus ces derniers temps, malgré ma reprise d'activité. 

### Ce que je compte faire bientôt

- J'ai attaqué [la refacto d'un projet AWS en simple projet Typescript Node.js hébergé sur un VPS](https://dev-freelance.fr/dev/je-lache-aws)
- Je vais bientôt créer mon premier projet [Fresh Deno](https://fresh.deno.dev/)

Le process d'onboarding me prend vraiment 100% de mon temps, donc je pense que je pourrais reprendre un rythme normal d'ici quelques temps.



nubelson-fernandes-Cc9Yso_xn4I-unsplash.jpg

large_nubelson-fernandes-Cc9Yso_xn4I-unsplash.jpg

medium_nubelson-fernandes-Cc9Yso_xn4I-unsplash.jpg

small_nubelson-fernandes-Cc9Yso_xn4I-unsplash.jpg

thumbnail_nubelson-fernandes-Cc9Yso_xn4I-unsplash.jpg

Après avoir passé près d'un an dans le monde de l'automobile. Je bascule dans la restauration. Moi qui aime bien manger, je suis servi !

J'ai changé de boulot

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

Me revoilà après quelques jours d'absences. 🥳️

Cela m'a fait du bien de prendre un petite pause avant d'attaquer de nouveau !

Sinon à mon retour, j'ai eu la frayeur de ma vie avec l'outil de backup du site dev-freelance. 😂

Pour info, faîte gaffe à votre **yarn** sur vos serveurs, il remplie souvent les répertoires **/tmp**, ce petit filou ! 🤔

### Où est-ce que j'étais tout ce temps ?

Je suis allé chercher un peu de soleil en Corse. 😄☀️

C'était très sympathique, voyez plutôt :

![dev-freelance-en-corse ><](https://bo.dev-freelance.fr/uploads/corse_5ab75b69ce.jpg)

### Qu'est-ce qu'il y a au menu ?

Beaucoup de changement, car depuis j'ai changé de client. Je suis passé du côté américain de la force. Mdr, sans trop rentrer dans les détails mais pour ceux qui me suivent sur Linkedin, vous pourrez facilement avoir l'info. Aussi je vous invite à m'ajouter car je partage beaucoup sur cette plateforme aussi.

#### Qu'est-ce que cela change ?

Qui dit changement de boulot dit souvent nouveaux process, nouveaux outils. Donc il y a de fortes chances que j'apprenne énormément de nouvelles choses que je vous partagerai prochainement.

### Un peu de lecture en attendant

Voici un petit cru de la sélection dev-freelance partagé sur twitter :

📰[Nobody ever got fired for buying AWS](https://chaordic.io/blog/nobody-ever-got-fired-for-buying-aws/) article qui traite de l'abus des coûts AWS (une raison pour laquelle je me suis tourné vers une petite infra VPS faite à la main).

📰[Des pilotes Vulkan pour RPI 4](https://www.01net.com/actualites/les-raspberry-4-vont-devenir-bien-plus-performants-en-3d-grace-aux-drivers-vulkan.html) grosse montée de FPS pour notre mini machine !

📰[Meta qui investie massivement dans une infra pour de l'IA](https://www.theregister.com/2022/07/28/meta_pours_cash_into_servers/). Ils sont toujours en phase de R&D mais cela annonce des changements majeurs dans l'avenir de la boîte. Il suffit d'une trouvaille pour que le cours de l'action explose ensuite, à bon entendeur... 😏

harshil-gudka-77zGnfU_SFU-unsplash (1).jpg

medium_harshil-gudka-77zGnfU_SFU-unsplash (1).jpg

small_harshil-gudka-77zGnfU_SFU-unsplash (1).jpg

thumbnail_harshil-gudka-77zGnfU_SFU-unsplash (1).jpg

Est-ce que j'ai été kidnappé par des extra-terrestres ? 👽 Est-ce que j'ai été happé par un trou noir ? 😂
Non je rentre de vacances !

Je suis de retour

## 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.

Découvrez tous nos articles - page 1 sur 4