### Pourquoi il n'est pas simple de modifier une table PostgreSQL directement en production ?

Lorsqu'il s'agit de votre base de données, la source de vérité sur laquelle vous vous appuyez pour des opérations, des calculs, ou même diffuser du contenu sur vos plateformes, **vous ne pouvez pas risquer de tout perdre**. Les enjeux sont importants au point que certaines compagnies prennent le temps de faire un backup de base avant ce genre d'opérations (il est notamment conseillé de le faire régulièrement). L'idée étant de pouvoir retomber sur vos pattes si vous rencontrez un problème. Cependant, vous conviendrez que si votre base fait 30go, le backup ne sera pas simple à faire.

Par ailleurs, il est difficile de mettre à jour une table de production car si l'opération est trop lourde pendant la modification de cette table, cela peut empêcher tout accès en parallèle. Ce qui implique littéralement un freeze de cette ressource pendant la durée de l'opération. Aussi, la question que vous devez vous poser est : **pouvez-vous vous permettre une interruption ?** Pour vous donner une idée, Amazon vend 150 produits par minutes. **Imaginer rendre une table produits inaccessible pendant 1 heure signifie se tirer une balle le pied !**

Donc, la gestion d'une base de données sur un projet actif n'est pas une mince affaire. 

### Les tâches obligatoires sur votre base

- 1. Toilettage Quotidien avec VACUUM

L'un des premiers défis réside dans le maintien de votre base de données en bonne santé au quotidien. C'est là que l'outil VACUUM entre en jeu. Il vous permet de récupérer de l'espace disque inutilisé suite aux suppressions, de prévenir la fragmentation, de nettoyer les transactions inachevées, et plus encore. La compréhension et l'utilisation appropriée de VACUUM sont cruciales pour maintenir la stabilité et la performance de votre base.

- 2. Optimisation de l'Architecture

Une architecture de base de données bien conçue est un élément clé de la performance. Savoir quand utiliser la redondance d'informations, c'est-à-dire répéter une colonne sur différentes tables pour éviter des jointures inutiles ou des sous-requêtes, peut considérablement accélérer vos requêtes.

- 3. Gestion du Volume de Données

Pour les projets de grande envergure, où des dizaines de sociétés vendent des milliers de produits chacune, le volume de données peut atteindre des dizaines, voire des centaines de gigaoctets. Il est essentiel de maintenir la base de données active dans une "tranche raisonnable" d'espace disque, idéalement en dessous de 1 Go pour garantir des performances optimales. Cela peut impliquer la mise en place d'une base de données active distincte de la base d'archives, avec des bascules périodiques pour libérer de l'espace et améliorer la réactivité de l'instance.

Il y a plusieurs façon de mettre à jour une table surtout si elle contient des données. Et par données, j'entends des dizaines, centaines de milliers de lignes, des millions voire plus. Croyez moi, à ce moment là, vous ne faîtes plus seulement un :

```
ALTER TABLE ADD COLUMN ... DEFAULT ...
```

Sous peine de mettre littéralement votre base de données en PLS ✝️.

Lorsque vous avez trop de données l'activation du **DEFAULT VALUE** peut faire très très mal à votre instance de base, le temps de passer sur chaque ligne pour y mettre la fameuse valeur par défaut. Au même moment, toutes les requêtes entrante vers cette table sont compromises, gros risques de perte d'accès à cause des **lock** de ressource etc. 


>Ne pas pouvoir répondre à une QUERY c'est une chose, mais perdre un INSERT/UPDATE/DELETE ça peut carrément être grave.

Il y a plusieurs façon de procéder dans ce cas de figure, certaines méthode sont plus complexes que d'autres, même si ce n'est pas mon domaine premier d'expertise (car je tiens à rappeler que c'est un métier à part entière et que nos experts **SysDBA**/**DBOps** sont biens plus qualifiés que moi pour vous aiguiller au mieux) je vais vous expliquer ce que je ferai dans ce cas. Bien sûr, ces méthodologies ont été testés et éprouvés sur le terrains avec mes confrères **DBOps** et sous couvert de leur expertise.

### 1- La nouvelle table

Il est tout à fait possible et plein de sens de créer une nouvelle table pour y effectuer les modification par rapport à une table initiale. On parle ici uniquement de la structure de table dans un premier temps.

Bien que cela comporte aussi ses inconvénients dans un second temps : 
Supposez que votre table principale fasse **10go**, cela signifie que vous allez vous retrouver avec le double, du moins, pendant un instant. Si vous êtes sur un serveur dont les limitations disque ne vous permettent pas d'aller aussi loin, cette procédure semble déjà compromise. 

Pour autant, cette méthode comporte aussi quelques avantages: 
**La sécurité et l'intégrité des données sur la table principale qui n'est pas altérée**, cela vous permet de structurer souplement vos colonnes et de prendre le temps d'améliorer le modèle. De plus, votre table principale est toujours accessible pour les utilisateurs. 

Une fois votre table terminée, vous pourrez à une heure de faible sollicitation (souvent le soir à 2h/3h du mat 🛏️), effectuer une bascule de données, via des batchs ou non. **Il est recommandé, pour avoir la garantie de récupérer 100% de l'état de la table initiale en sortie, d'utiliser des lock manuels pendant l'opération**. 

Cette solution est tout à fait convenable et fonctionne très bien. Quand votre opération est terminée, rien ne vous empêche de renommer les tables pour que la nouvelle puisse enfin remplacer l'ancienne.

### 2- Le batch update sur la table cible

Une autre alternative vous est possible : **directement modifier la table cible** !

>Cependant, pas si vite jeune fougeux(se) ! ✋

Rappelez vous ce que je vous ai dit plus haut, on ne fait pas un **ALTER TABLE** gratuit sur une table avec une **DEFAULT VALUE**. Votre base va cracher ses poumons ! 😷 

Pour cela je vous propose un peu d'algorithme et d'élégance pour paraphraser un ancien confrère.  

Voici un exemple de batch que je ferai, je batcherai par lot de 1000 les lignes afin de ne pas saturer ma base. De cette façon, j'ai plus de garantie qu'elle reste accessible en parallèle pour tout autre accès.

```
DO $$
DECLARE
  total_rows FLOAT; -- we need a float to calculate coeff 
  total_pages INTEGER; 
  pg_offset INTEGER = 1000; -- our limit for each iteration
  id_val INTEGER;
  temp_row RECORD;
BEGIN
  SELECT INTO total_rows count(*) FROM movies;
  total_pages = ceil(total_rows / pg_offset);
  
  -- log infos
  RAISE NOTICE 'Total rows: %', total_rows; 
  RAISE NOTICE 'Pages count: %', total_pages; 
  
  -- add new column without default value 
  ALTER TABLE movies ADD COLUMN in_collection BOOLEAN;
  
  -- batch update value
  FOR id_val IN 1..total_pages
  LOOP
    RAISE NOTICE 'Updating page % of %', id_val, total_pages; 
  	FOR temp_row IN
  	  SELECT * FROM movies LIMIT pg_offset offset pg_offset * (id_val - 1)
	LOOP
	  UPDATE movies SET in_collection=true WHERE id = temp_row.id;
	  COMMIT;
	END LOOP;
  END LOOP;
  
  RAISE NOTICE 'Job done, Rest soldier !';
  
END $$;
```

⚠️ Petite subtilité: l'usage du **FLOAT** pour **total_rows** est important pour la variable de coefficient. 

Le passage, même temporaire à un état flottant, bien que le **CEIL()** va suivre, est obligatoire ! Si vous déclarez cette variable en **INTEGER**, vous rencontrez un problème lors de l'opération 

```
CEIL(var / 1000); 
```

Si **var = 1300**, **var / 1000** ne sera plus 1.3 mais 1 et ça change tout avant exécution du **CEIL**. Oui, même si vous n'assignez pas le fameux 1.3 à votre **var** !  👈

__

Parenthèse fermée, rien ne vous empêche, quand tout est fini de faire un **ALTER COLUMN** et d'y ajouter votre **DEFAULT VALUE**. Au moins, on sait que les opérations d'écritures sont terminées.

Les notices permettent de suivre dans la console ce qu'il se passe pour ne pas vous faire poireauter à l'aveugle. 

Pour information, j'ai lancé cette requête sur une base temporaire de films avec exactement 7392 lignes et voici l'output console :

```
NOTICE:  Total rows: 7392
NOTICE:  Pages count: 8
NOTICE:  Updating page 1 of 8
NOTICE:  Updating page 2 of 8
NOTICE:  Updating page 3 of 8
NOTICE:  Updating page 4 of 8
NOTICE:  Updating page 5 of 8
NOTICE:  Updating page 6 of 8
NOTICE:  Updating page 7 of 8
NOTICE:  Updating page 8 of 8
NOTICE:  Job done, Rest soldier !
DO

Query returned successfully in 11 secs 493 msec.
```

**11.5sec pour 7392 lignes** ça laisse présager de ce que ça serait avec 10 millions de lignes. En extrapolant un peu, on serait au alentours de 4H30... 

Rien ne vous empêche de mettre des **hard limit** à vos batchs par exemple, d'ajouter des conditions pour s'arrêter à 1 000 000 de lignes, en vous obligeant ainsi à relancer plusieurs fois le script mais au moins vous aurez la possibilité de faire des contrôles entre les exécutions. N'oubliez pas ceci-dit, de commenter (double dash/tiret) la partie **ADD COLUMN** si vous le faites.

Pour conclure, je dirai que des solutions possibles pour faire une mise à jour de la structure de table en production sont :
- le backup de table et l'exécution brute des requêtes **ALTER TABLE** (bien que déconseillée)
- la nouvelle table et la copie incrémentale avec un batch  **SELECT** -> **INSERT** (bien que nécessitant un espace disque suffisant)
- le batch opération sur la table elle même 

C'est tout pour cet article qui j'espère vous apportera une solution dans vos problématiques quotidiennes. N'hésitez pas à le partager si vous avez apprécié, ou à me faire vos retours en commentaire ou sur la rubrique contact du site. Oui, je lis les messages ! 😉

large_warehouse.jpg

medium_warehouse.jpg

small_warehouse.jpg

thumbnail_warehouse.jpg

warehouse.jpg

Lorsque l'on veut modifier une table sur une base de production PostgreSQL, il convient de s'y ateler avec beaucoup de précautions. Bien sûr, tout va dépendre de la criticité de la base, de la fréquence d'utilisation, du volume de données etc... Mais en pratique, lorsqu'il s'agit de votre production il faut se préparer à une procédure très technique.

Comment modifier une grosse table PostgreSQL

Contrairement à ce que je peux laisser entendre dans mes écrits, Node.js a beau être ma techno préféré, JS/TS le langage dans lequel je me sens le plus à l'aise. Ce n'est pas le meilleur outil dans toutes les situations. 

Il y a effectivement de nombreuses possibilités notamment via les **spawn** etc pour faire des appels de commande terminal, mais l'async rend les choses un peu plus compliqués lorsque l'on veut uniquement séquencer des opérations.

Quand je parle de scripting, je parle d'opérations que j'exécute sur ma machine, mon OS, mon infra ou encore des scripts de scraping. Et je pense que **Python** est un outil bien plus adapté pour ce genre de chose.

## Pourquoi ? 

N'en déplaise aux fanboys Node.js de la première heure, **Python** est beaucoup plus puissant en terme d'outil. 

Dans 95% des cas (chiffre qui sort de ma tête, mais qu'on se le dise, qui ne doit pas être loin de la réalité), des gens se concentrent uniquement sur des fonctionnalités basiques lorsqu'ils font du scraping. 

Ils diront : **Puppeteer** c'est suffisant ! **Cypress** c'est trop cool, ou encore **Selenium** pour les plus techniques. 

Mais les gars, je vous mets au défi de créer un système bien plus complexe ou les interactions deviennent dynamique, etc... Par exemple, brancher vos scrapers sur des plateformes qui n'ont pas été adaptés pour la situation (login compris, captcha compris, sans détourner le système de connexion). Car la plupart du temps pour de l'automatisation E2E, les process sont adaptés pour gérer les scénarios de tests plus facilement. Et bien **Python** il peut faire tout ça, sans alléger le process et sans trop vous casser la tête.

## Compliqué ? 

Python permet de faire tellement de chose: 
- la lecture d'écran grâce à l'**opencv** (pour Open Computer Vision), c'est à dire être capable de prendre en entrée une image (typiquement ce sera un screenshot de votre page). 
- la prise en main de votre machine, déplacer la souris à votre place, taper au clavier à votre place etc...
- et pour pousser un peu plus, vous pouvez y ajouter un système de réseau de neurones si vous voulez y intégrer l'apprentissage et que votre système puisse évoluer

Figurez vous que Python fait tout cela facilement et sans broncher...


<iframe width="315" height="560"
src="https://www.youtube.com/embed/BUK0f-3R_qU"
title="YouTube video player" frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media;
gyroscope; picture-in-picture;
web-share"
allowfullscreen></iframe>

Par ailleurs, non je ne télécharge pas 🙈 ... Il faut bien que je teste quelque part 😇

Donc, je penses toujours que **Node.js** est le meilleur langage pour processer des pages sur un serveur grâce à son moteur fait pour l'i/o. 

Mais, ne restez pas dans votre zone de confort et explorez tous les langages car à chaque problème sa solution. Parfois un autre langage peut être un outil bien plus adapté à votre besoin.

todd-quackenbush-IClZBVw5W5A-unsplash.jpg

large_todd-quackenbush-IClZBVw5W5A-unsplash.jpg

medium_todd-quackenbush-IClZBVw5W5A-unsplash.jpg

small_todd-quackenbush-IClZBVw5W5A-unsplash.jpg

thumbnail_todd-quackenbush-IClZBVw5W5A-unsplash.jpg

Est-ce qu'en tant que développeur Typescript je ne fais que du ts ? Je ne jure que par lui et rien d'autre ? Et bien la réponse est non ! TS est un super langage pour coder des API et du frontend. Cependant, lorsque je code un script, automate, système ou autre, j'utilise autre chose.

Mon langage de scripting préféré

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

Découvrez tous nos articles - page 5 sur 9