Anthony, Engineering Lead, vingt ans de code. Autodidacte : de l'usine au cybercafé, jusqu'aux systèmes que tu utilises tous les jours.


Anthony Capirchio

Salut, moi c'est Anthony, développeur dans le monde du web depuis une vingtaine d'années. Je suis autodidacte, c’est-à-dire que je me suis formé moi-même. Comme pas mal d'autodidactes, j'ai avant tout cherché à découvrir le code à travers la résolution de problèmes sans forcément m'attarder sur les fondamentaux ainsi que sur les aspects plus bas niveau.
Si j'ai publié ce site, c'est pour revenir sur ce que j'aurais aimé connaître ou comprendre plus tôt dans mon aventure de développeur.
Quel que soit ton niveau, j'espère que ce site te permettra de découvrir ou redécouvrir certains aspects techniques.

Les fondamentaux qui survivent à l'IA, expliqués par un autodidacte qui a fait le chemin, et qui recrute aujourd'hui ceux qui le commencent.

On ne naît pas dev, on le devient.


L'API, ou "Application Programming Interface", est un outil qui permet à différents programmes informatiques de communiquer entre eux. En d'autres termes, c'est un moyen pour que différentes applications puissent échanger des données et interagir ensemble.

Prenons un exemple concret : imaginez que vous utilisez une application pour commander de la nourriture en ligne. Lorsque vous passez votre commande, cette application va utiliser une API pour envoyer les détails de votre commande à un système de paiement en ligne. Le système de paiement va alors vérifier si votre paiement est valide, et renvoyer une confirmation de paiement à l'application de commande de nourriture.

Les APIs sont très utiles car elles permettent aux différentes applications de travailler ensemble de manière fluide et efficace. Elles sont également très pratiques pour les développeurs, qui peuvent utiliser des APIs pour ajouter de nouvelles fonctionnalités à leurs applications sans avoir à tout recommencer à zéro.

Une API permet à différentes applications de communiquer et d'échanger des données. Elles sont utiles pour permettre aux applications de travailler ensemble de manière fluide et sont pratiques pour les développeurs qui peuvent ajouter de nouvelles fonctionnalités à leurs applications sans avoir à tout refaire.


Le bus en informatique est un élément central de l'architecture d'un ordinateur. C'est un canal de communication qui relie différents composants de l'ordinateur entre eux. Le bus permet aux différents éléments de l'ordinateur de communiquer entre eux, de manière à pouvoir échanger des données et des instructions.

Prenons un exemple concret : imaginez que vous souhaitez lire un fichier stocké sur votre disque dur. Lorsque vous cliquez sur le fichier, votre processeur va envoyer une instruction au disque dur via le bus. Le disque dur va alors envoyer les données du fichier au processeur via le bus, qui va les afficher à l'écran.

Le bus est donc un élément crucial de l'ordinateur, qui permet aux différents composants de communiquer entre eux. Il existe différents types de bus, qui varient selon la vitesse de communication et la quantité de données qu'ils peuvent transférer.


Le bus en informatique est un canal de communication qui relie les composants d'un ordinateur entre eux, permettant aux éléments de l'ordinateur de communiquer et d'échanger des données et des instructions.

Un cas limite, c'est l'entrée rare qui tombe pile à la frontière de ce que ton code prévoyait : la valeur zéro, la chaîne vide, le caractère qu'on n'attendait pas. Le programme marche pour tout le monde, sauf pour lui, et c'est précisément là qu'il casse en silence.

Le « + » dans une adresse email est un cas limite d'école : valide pour la norme, refusé par un formulaire qui n'avait testé que des adresses « normales ».

À lire : [Ne mens pas à tes utilisateurs](/blog/ne-pas-mentir).


L'entrée rare qui tombe pile à la frontière de ce que ton code prévoyait, et où il casse en silence.

Cas limite

Quand un serveur répond à une requête, il commence toujours par un nombre à trois chiffres qui résume le sort de ta demande : 200 si tout va bien, 404 si la page n'existe pas, 500 s'il s'est cassé. C'est le premier mot du serveur, avant même le contenu, et souvent le plus honnête, parce qu'il range la réponse dans une catégorie précise au lieu de la noyer.

Le dimanche soir où un formulaire a renvoyé un 417 à ma femme sans jamais l'afficher, le code disait déjà tout : demande rejetée, et le serveur savait pourquoi.

À lire : [Ne mens pas à tes utilisateurs](/blog/ne-pas-mentir).


Le nombre à trois chiffres par lequel un serveur résume le sort de ta requête, avant même d'envoyer le contenu.

Code de statut HTTP

Les cookies sont de petits fichiers texte stockés sur votre ordinateur lorsque vous naviguez sur internet. Ils permettent aux sites web de mémoriser des informations sur vos préférences et votre historique de navigation afin d'améliorer votre expérience en ligne.

Les cookies sont gérés par les navigateurs web (comme Google Chrome ou Mozilla Firefox) et peuvent être utilisés par les API (Application Programming Interface) pour stocker des données sur un serveur distant.

Un cas d'utilisation courant des cookies est lorsque vous vous connectez à un site web avec votre compte utilisateur. Le site enregistre un cookie sur votre ordinateur afin de vous identifier lors de votre prochaine visite et de vous offrir un accès rapide à votre compte.

Les cookies peuvent également être utilisés pour enregistrer vos préférences de navigation, comme les articles que vous avez consultés ou les produits que vous avez ajoutés à votre panier d'achat. Cela permet au site web de personnaliser votre expérience en ligne en fonction de vos goûts et de vos intérêts.

Les API peuvent également utiliser des cookies pour stocker des informations sur un serveur distant. Par exemple, si vous utilisez une application mobile pour accéder à un site web, l'API peut utiliser un cookie pour stocker vos informations de connexion sur le serveur, afin de vous permettre de vous connecter rapidement lors de votre prochaine utilisation de l'application.

En résumé, les cookies sont des fichiers texte utilisés par les navigateurs web et les API pour stocker des informations sur votre ordinateur et améliorer votre expérience en ligne. Ils peuvent être utilisés pour enregistrer vos préférences de navigation, votre historique de navigation et vos informations de connexion pour un accès rapide à vos comptes utilisateur.

Les cookies sont des petits fichiers stockés sur l'ordinateur d'un utilisateur par un site web pour enregistrer des informations sur ses préférences et ses activités en ligne.

Cookie

Les entêtes CORS, ou "Cross-Origin Resource Sharing", sont une série d'entêtes HTTP qui permettent de contrôler l'accès à des ressources web depuis un autre domaine. Ces entêtes sont utilisées pour gérer les requêtes de type "cross-origin", c'est-à-dire lorsqu'une ressource est demandée depuis un autre domaine que celui auquel elle appartient.

Par exemple, imaginons que vous avez un site web qui affiche des données provenant d'une API externe. Lorsque vous effectuez une requête à cette API depuis votre site, le navigateur web va envoyer une demande de type "cross-origin" au serveur de l'API. Le serveur de l'API va alors vérifier les entêtes CORS envoyées par le navigateur, afin de déterminer s'il doit autoriser ou non l'accès à la ressource demandée.

Les entêtes CORS sont donc très utiles pour gérer l'accès aux ressources web depuis différents domaines. Elles permettent de contrôler qui peut accéder à ces ressources, et de protéger les données des utilisateurs contre les accès non autorisés.

CORS


Docker est un logiciel qui permet de créer, de déployer et d'exécuter des applications dans des conteneurs. Un conteneur est une sorte d'environnement isolé qui contient tout ce dont l'application a besoin pour fonctionner, comme les bibliothèques, les fichiers de configuration et les dépendances.

En utilisant Docker, les développeurs peuvent créer des applications dans des conteneurs sur leur ordinateur local et être sûrs qu'elles fonctionneront de la même manière une fois déployées sur un serveur ou un autre ordinateur. Cela permet de faciliter le déploiement d'applications et de s'assurer que tous les membres de l'équipe de développement utilisent la même configuration.

La virtualisation est une technologie qui permet de faire fonctionner plusieurs systèmes d'exploitation et leurs applications sur un seul ordinateur physique. Cela permet d'utiliser plusieurs ordinateurs virtuels sur un seul ordinateur physique, ce qui peut être utile pour exécuter des applications qui ont des exigences spécifiques en matière de système d'exploitation ou pour s'assurer que les applications sont isolées les unes des autres.

La différence entre Docker et la virtualisation réside principalement dans la façon dont les applications sont exécutées. Avec Docker, les applications sont exécutées dans des conteneurs qui partagent le même système d'exploitation que l'ordinateur sur lequel ils sont déployés. Cela permet de créer des conteneurs plus légers et plus rapides à déployer que des machines virtuelles complètes.

En résumé, Docker est une technologie qui permet de créer, de déployer et d'exécuter des applications dans des conteneurs, tandis que la virtualisation permet de faire fonctionner plusieurs systèmes d'exploitation et leurs applications sur un seul ordinateur physique. Docker est souvent considéré comme une solution plus légère et plus rapide que la virtualisation, mais cela dépend des besoins de l'application et de l'environnement de déploiement.

Docker est une technologie qui permet d'empaqueter et de déployer des applications dans des conteneurs logiciels isolés.

Docker

Les codes de statut HTTP se rangent en familles. Les 4xx désignent une erreur du côté de celui qui demande (400 mauvaise requête, 403 interdit, 404 introuvable) : le problème est chez toi, et il est souvent corrigeable. Les 5xx désignent une panne du côté du serveur (500 erreur interne, 503 indisponible) : là, tu ne peux qu'attendre.

Tout le drame du formulaire de ma femme tient dans cette confusion : un 4xx corrigeable en deux secondes, affiché comme s'il n'y avait plus rien à faire.

À lire : [Ne mens pas à tes utilisateurs](/blog/ne-pas-mentir).


Les 4xx disent que le problème est chez celui qui demande (souvent corrigeable) ; les 5xx, qu'il est chez le serveur (tu ne peux qu'attendre).

Erreur 4xx vs 5xx

C’est un sujet qui revient régulièrement dans les questions d’entretiens d’embauche : Que se passe-t-il lorsque nous entrons une url dans notre navigateur et pressons la touche “entrer” ?

Cette question est particulièrement pertinente pour diverses raisons : 

- Elle permet d’évaluer le niveau de connaissance générale du candidat sur le fonctionnement d’internet et de l’informatique
- Elle permet d’évaluer la capacité du candidat à être synthétique
- Elle permet également de voir si le candidat sait dire qu’il ne sait pas

Si j’en parle ici c’est surtout parce que c’est également un excellent fil rouge pour apprendre ou réapprendre comment fonctionne le web.

Nous allons revenir sur la vision macro dans cet article et appuyer, au fur et à mesure, les propos avec des articles dédiés.

## **Étape 1 : Parsing de l’URL**

Une URL comme `https://www.exemple.net/demo?user=1234` doit être décomposée pour que le navigateur puisse l’exploiter. C’est ce qu’on appelle le **parsing de l’URL**. Voici les principaux éléments d’une URL :

- **Protocole/Scheme** : Définit le mode de communication. `https://` indique une connexion sécurisée via HTTPS.
- **Domaine** : `www.exemple.net` est utilisé pour identifier le serveur.
- **Chemin (Path)** : `demo` spécifie la ressource à récupérer sur le serveur.
- **Query String** : `?user=1234` contient des paramètres transmis avec la requête.

Cette étape permet au navigateur de préparer la requête réseau.

## **Étape 2 : Vérification du cache**

“tu as bien vidé ton cache ?” - Si c’est une esquive, c’est aussi  une réalité.

Avant d’envoyer une requête réseau, le navigateur vérifie si la page ou ses ressources (HTML, CSS, images, JavaScript) sont déjà disponibles dans son **cache local** afin d’économiser une requête. 

Le cache permet de réduire le temps de chargement et l’utilisation du réseau :

- Si une copie valide est trouvée, elle est directement utilisée.
- Si le contenu a expiré (selon les directives envoyées par le serveur), une requête réseau est lancée.

Le cache peut inclure des copies partielles ou complètes des ressources, optimisant ainsi le chargement des pages fréquemment visitées.

## **Étape 3 : Résolution DNS**

Si le cache ne contient pas de réponse valide, le navigateur doit traduire le domaine en une **adresse IP** via le DNS (Domain Name System). Le DNS agit comme un annuaire pour transformer un domaine comme `www.exemple.net` en une adresse IP comme `93.184.216.34` , car si l’utilisation d’un nom de domaine facilite grandement sa mémorisation, la communication entre un client et un serveur se fait exclusivement avec une adresse IP.

Voici les étapes principales de la résolution DNS :

1. Le navigateur vérifie son propre cache DNS local.
2. Si aucune correspondance n’est trouvée, il interroge un **serveur DNS récursif** (souvent fourni par le FAI).
3. Ce serveur DNS peut lui-même consulter d’autres serveurs :
    1. Les **serveurs racine** pour identifier le TLD (Tope Level Domain - ex. .net).
    2. Les **serveurs d’autorité** pour récupérer l’adresse exacte.
4. Une fois l’adresse IP obtenue, elle est renvoyée au navigateur.

Ce processus peut impliquer plusieurs requêtes, souvent transmises via UDP.

## **Étape 4 : Ouverture de la connexion TCP**

Avec l’adresse IP en main, le navigateur établit une connexion réseau avec le serveur. Cela passe par le protocole TCP (Transmission Control Protocol), qui garantit une communication fiable grâce au **handshake à trois étapes** :

1. Le client envoie un paquet **SYN** (synchronisation) au serveur.
2. Le serveur répond avec un paquet **SYN-ACK** (synchronisation + acquittement).
3. Le client termine avec un paquet **ACK** (acquittement).

Pour les connexions sécurisées via HTTPS, un **handshake TLS** suit immédiatement. Ce dernier utilise des certificats pour authentifier le serveur et chiffrer les échanges.

## **Étape 5 : Envoi de la requête HTTP**

Une fois la connexion TCP ouverte, le navigateur envoie une **requête HTTP** pour demander la ressource. Cette requête inclut :

- **Méthode** : La plupart des requêtes initiales utilisent la méthode GET.
- **En-têtes** : Contiennent des métadonnées, comme le type de navigateur (*User-Agent*) ou les cookies.
- **Paramètres** : Transmettent les informations nécessaires au serveur via l’URL ou le corps de la requête (pour POST).

Avec HTTP/2 ou HTTP/3, les navigateurs modernes optimisent ce processus grâce à la multiplexation, permettant de charger plusieurs ressources en parallèle.

## **Étape 6 : Traitement de la requête par le serveur**

Une fois la requête reçue, le serveur effectue les opérations nécessaires pour fournir une réponse :

1. **Identification de la ressource** : Le serveur détermine si le fichier demandé existe.
2. **Traitement applicatif** : Pour les sites dynamiques, le serveur peut exécuter du code (ex. PHP, Go) et interroger une base de données.
3. **Génération de la réponse HTTP** : Inclut le code de statut (200 pour succès, 404 pour non trouvé, etc.) et le contenu demandé.

La réponse est ensuite encapsulée dans des paquets TCP pour être renvoyée au navigateur.

## **Étape 7 : Réception et affichage des ressources**

Lorsque le navigateur reçoit la réponse, il commence immédiatement à traiter les ressources :

1. Le HTML est analysé pour construire le **DOM** (Document Object Model), une représentation hiérarchique des éléments de la page.
2. Les fichiers CSS sont chargés et appliqués pour déterminer le style et la mise en page.
3. Les scripts JavaScript sont exécutés pour ajouter de l’interactivité.

Ces étapes, appelées **parsing**, **layout** et **painting**, sont gérées par le moteur de rendu du navigateur (comme Blink pour Chrome). Pendant ce temps, des requêtes supplémentaires sont envoyées pour charger les ressources manquantes (images, polices, etc.).

Comprenez les étapes clés qui se déroulent lorsque vous entrez une URL dans votre navigateur : parsing, cache, résolution DNS, connexion TCP, requête HTTP, et rendu des ressources. Un guide essentiel pour maîtriser le fonctionnement du web.

Navigateur


Dans le monde de l’IT, comme dans bien d’autres domaines, les incidents ne surviennent pas à cause d’une seule défaillance, mais souvent en raison d’une série de petites erreurs ou failles qui, mises bout à bout, mènent à un désastre. C’est là que le **modèle du gruyère** trouve tout son sens.

## **Le modèle du gruyère : Définition et origine**

Proposé initialement par James Reason dans le domaine de la gestion des risques et de la sécurité aérienne, le modèle du gruyère visualise les défenses d’un système sous forme de couches successives de fromage. Chaque tranche représente une **barrière** ou une **mesure de protection** contre les risques.

Cependant, aucune barrière n’est parfaite : chaque tranche possède des trous (des **failles** ou **vulnérabilités**) qui, isolément, ne posent pas de problème majeur.

Mais lorsque ces trous s’alignent à travers plusieurs tranches, un chemin direct se crée, permettant à un incident critique de se produire. C’est l’alignement des failles qui est à l’origine des catastrophes.

Dans l’IT, ce concept trouve une application directe dans des domaines tels que la **cybersécurité**, la **gestion des incidents**, le **développement logiciel**, et bien d’autres.

## **Comment réduire l’alignement des trous : La défense en profondeur en action**

Réduire l’alignement des trous dans le modèle du gruyère ne signifie pas chercher à éliminer toutes les failles, ce qui serait irréaliste. En revanche, il s’agit de construire un système résilient grâce à une **stratégie de défense en profondeur**, où chaque couche joue un rôle spécifique et complémentaire.

Explorons les différentes manières de renforcer ces couches et de limiter le risque d’un alignement catastrophique.

### **1. Automatiser les processus pour limiter les erreurs humaines**

Les erreurs humaines sont une des principales sources de vulnérabilités dans les systèmes IT. Pour pallier cela, l’automatisation est une solution puissante. Par exemple :

- **Infrastructure as Code (IaC)** : Utiliser des outils comme Terraform ou AWS CloudFormation permet de configurer et de déployer l’infrastructure de manière répétable et sans erreur humaine. Cela réduit les risques liés à des configurations manuelles, comme des permissions mal définies ou des ouvertures réseau non intentionnelles.
- **Tests automatisés** : Mettre en place une batterie de tests unitaires, d’intégration, et de tests end-to-end dans le pipeline de CI/CD garantit que chaque modification est validée avant son déploiement. Cela crée une barrière solide contre l’introduction de bugs en production.
- **Alertes dynamiques** : Les systèmes de monitoring peuvent utiliser des algorithmes basés sur des modèles (machine learning ou basiques comme les seuils adaptatifs) pour générer des alertes plus pertinentes. Cela élimine les faux positifs et permet une réponse rapide en cas de problème réel.

L’automatisation ne remplace pas les humains, mais elle réduit leur exposition aux tâches répétitives et sujettes aux erreurs, leur permettant de se concentrer sur les problèmes complexes.

### **2. Multiplier les couches de défense**

La diversité des couches de défense est essentielle pour absorber les chocs et éviter qu’une faille ne traverse tout le système. C’est l’idée clé de la défense en profondeur (Defense in Depth). Chaque couche compense les faiblesses des autres, créant ainsi un système résilient.

- **Sécurité périmétrique** : Les pare-feux et les proxies agissent comme des barrières extérieures. Ils filtrent le trafic et empêchent les accès non autorisés. Mais ils ne peuvent pas tout voir, surtout en cas d’attaques internes ou d’erreurs de configuration.
- **Authentification forte** : L’implémentation de solutions comme l’authentification multi-facteurs (MFA) ou les certificats numériques renforce la sécurité des identités. Ainsi, même si un mot de passe est compromis, l’accès non autorisé reste bloqué.
- **Chiffrement des données** : Que ce soit pour les données en transit (TLS) ou au repos (AES-256), le chiffrement garantit que même si une intrusion se produit, les données restent inutilisables pour l’attaquant.
- **Segmentation réseau** : Plutôt que d’avoir un réseau monolithique, la segmentation isole les environnements sensibles (par exemple, les bases de données) du reste du réseau. Si une partie du système est compromise, l’attaque ne peut pas se propager facilement.
- **Surveillance continue** : Des systèmes comme Prometheus, Datadog ou Splunk détectent les anomalies en temps réel. Cette surveillance agit comme une barrière proactive qui identifie les comportements anormaux avant qu’ils ne causent des dégâts.

Chaque couche est imparfaite, mais leur combinaison rend le système beaucoup plus robuste face aux menaces.

### **3. Apprendre des incidents passés : Les post-mortems**

Les incidents, même désagréables, sont une opportunité précieuse pour apprendre. Lorsqu’un problème survient, il est crucial de conduire un **post-mortem** rigoureux pour identifier :

- **Les causes profondes** : Quels trous se sont alignés pour permettre l’incident ?
- **Les actions correctives** : Comment renforcer les défenses pour éviter que ce type de problème ne se reproduise ?
- **Les points de friction organisationnels** : Par exemple, un manque de communication entre équipes ou une procédure mal documentée.

Un bon post-mortem n’a pas pour but de blâmer, mais de construire un système plus résilient. Les conclusions doivent être partagées et intégrées dans les processus pour que l’ensemble de l’organisation en bénéficie.

### **4. Simuler les crises : Tester avant que les problèmes n’arrivent**

Attendre qu’un incident survienne pour tester ses défenses est une stratégie risquée. Les simulations permettent d’anticiper et de repérer les failles avant qu’elles ne soient exploitées. Parmi les pratiques courantes, on retrouve :

- **Pré-mortems** : Contrairement aux post-mortems, cette approche consiste à imaginer ce qui pourrait mal tourner avant qu’un projet ne démarre. L’équipe réfléchit aux risques potentiels et propose des solutions proactives.
- **Chaos engineering** : Des outils comme Chaos Monkey injectent volontairement des pannes dans les systèmes pour tester leur résilience. Cette méthode aide à repérer les points faibles et à s’assurer que les systèmes peuvent continuer à fonctionner malgré des perturbations.
- **Exercices de réponse aux incidents** : Simuler une panne ou une cyberattaque permet de tester les processus d’escalade, la communication entre les équipes et l’efficacité des procédures en place. Ces exercices mettent souvent en lumière des trous inattendus dans les défenses.

### **5. Former les équipes : Une défense humaine essentielle**

Même avec les meilleures technologies et processus en place, les équipes restent la première ligne de défense. Des collaborateurs mal formés ou mal informés peuvent devenir des maillons faibles, alors qu’un personnel compétent et conscient des risques peut faire toute la différence.

- **Sensibilisation à la sécurité** : Former les employés aux bonnes pratiques, comme la détection de phishing ou la gestion des mots de passe, réduit significativement les risques d’erreurs humaines.
- **Formation technique continue** : Les équipes IT doivent rester à jour sur les dernières technologies, vulnérabilités, et solutions. Par exemple, comprendre comment fonctionne un zero-day ou maîtriser les outils de monitoring modernes est essentiel pour maintenir une posture de sécurité optimale.
- **Partage des connaissances** : Encourager la documentation et le partage des apprentissages au sein des équipes garantit que les savoirs ne sont pas concentrés dans les mains de quelques experts, rendant ainsi l’organisation plus résiliente.

**La défense en profondeur, un investissement obligatoire**

Adopter une approche de défense en profondeur exige du temps, des ressources, et une coordination interdisciplinaire. Chaque couche de défense a un coût, mais l’absence de ces couches peut coûter bien plus cher en cas d’incident majeur. En combinant **technologie**, **processus**, et **formation**, les organisations peuvent limiter le risque d’alignement des failles et construire des systèmes capables de résister aux imprévus.

La clé est d’accepter qu’aucun système n’est parfait, mais qu’en renforçant chaque tranche du gruyère, nous réduisons considérablement les chances qu’une faille traverse toutes les couches. C’est un effort continu, mais les résultats en termes de stabilité, de sécurité et de résilience en valent largement la peine. 🧀

Découvrez comment le modèle du gruyère s’applique à l’IT pour comprendre et réduire les risques grâce à une défense en profondeur. Sécurité, résilience, et bonnes pratiques au cœur de vos systèmes.

Défense en profondeur et modèle du gruyère


Un dimanche soir, ma femme remplit un formulaire en ligne pour la retraite de son père. Elle valide. Écran gris : « Erreur technique, veuillez réessayer plus tard. » Elle recommence. Même mur. Elle change de navigateur, vérifie sa connexion, réessaie une troisième fois. Toujours le même écran. Le support est fermé, on est dimanche, et le dossier est urgent.

Réflexe de vieux dev, j'ouvre la console du navigateur. Et là, dans la réponse du serveur, en clair, la vérité que personne n'avait affichée : « Le format de l'email n'est pas conforme. » Code 417. Le coupable, on l'a trouvé en dix secondes : le « + » dans son adresse, `prenom+retraite@gmail.com`. Une adresse parfaitement valide, que ce formulaire refusait sans le dire.

Le système savait. Il savait exactement ce qui n'allait pas. Il a choisi de ne pas le lui dire.

Un message d'erreur qui n'affiche pas ce que le système sait, ce n'est pas une maladresse d'interface. C'est un mensonge par omission. La bonne information existait : précise, exacte, déjà écrite, prête à être lue. Quelqu'un dans la chaîne l'a remplacée par « erreur technique ». Ma femme n'était pas face à un bug. Elle était face à un système qui connaissait la réponse et qui a préféré se taire.

## Ce qui se passe entre le clic et l'écran

Quand tu soumets un formulaire, l'erreur peut naître à deux endroits. D'abord dans ton navigateur, la validation côté client : celle qui vérifie en direct qu'un champ n'est pas vide, qu'un email ressemble à un email. Elle est immédiate, mais elle ne fait pas autorité, parce qu'on peut toujours la contourner. Ensuite sur le serveur, la validation côté serveur : celle qui tranche pour de vrai, parce que c'est elle qui garde la porte de la base de données. Dans l'histoire de ma femme, le « + » est passé devant le client et s'est fait refuser par le serveur. Normal, c'est son rôle.

Et le serveur a bien fait son travail. Il a renvoyé deux choses. Un code de statut HTTP, 417, sa façon de dire « je refuse, et voici dans quelle catégorie ». Et un corps de réponse contenant la phrase exacte : « Le format de l'email n'est pas conforme. » Le protocole HTTP est honnête par construction : il possède tout un vocabulaire de codes pour distinguer « c'est toi qui as fait une erreur » de « c'est moi qui suis cassé ». La vérité a été émise. Complète. Utilisable.

Puis cette vérité remonte vers l'interface. Et c'est là qu'elle meurt. Quelque part dans le front, un bout de code attrape l'erreur et fait, en substance : `catch (e) { afficher("Erreur technique") }`. Un attrape-tout. Peu importe la cause (email invalide, session expirée, serveur en feu), tout se déverse dans la même phrase creuse. Le corps de la réponse, celui qui contient la raison précise, est là, à portée de main dans l'objet d'erreur. Le code le jette à la poubelle sans le lire.

Pourquoi la vérité se perd-elle en route ? Pas par malveillance. Par facilité. Gérer une erreur précisément, c'est du travail : lire le corps, distinguer les cas, écrire un message pour chacun. Un seul attrape-tout couvre tout et ne plante jamais. C'est le chemin de moindre résistance, celui qui se déguise en robustesse. On croit protéger l'utilisateur du chaos ; on lui cache juste la seule information dont il avait besoin.

Le cœur de l'affaire tient dans une distinction. Un code qui commence par 4 (les 4xx) dit : « le problème est chez toi, et je te dis lequel ». Il est actionnable, l'utilisateur peut corriger. Un code qui commence par 5 (les 5xx) dit : « le problème est chez moi », et là, l'utilisateur ne peut qu'attendre. Écraser les deux sous le même « erreur technique », c'est répondre « c'est ma faute, patiente » à quelqu'un qui avait juste une faute de frappe corrigeable en deux secondes. Voilà le mensonge : tu rends l'utilisateur impuissant devant un problème qu'il pouvait résoudre seul.

À l'usine, on ne mettait pas un seul voyant rouge « panne » sur une machine. Le bourrage papier que tu dégages à la main et le moteur grillé qui demande un technicien n'allument pas la même lampe. Sinon tu appelles la maintenance pour un bout de carton coincé, et tu attends une heure ce que tu aurais réglé d'un geste. « Erreur technique », c'est le voyant rouge unique. Le formulaire de ma femme n'avait qu'une seule lampe.

## Ce que l'IA change à ça

Maintenant que l'assistant écrit une partie de ton code, ce `catch` générique est encore plus le réglage par défaut. Demande-lui une gestion d'erreur, et la génération te sortira un attrape-tout avec un « une erreur est survenue » bien poli : c'est le motif statistiquement le plus sûr, celui qui compile partout et ne casse aucun écran. La machine optimise pour « ça build et ça ne plante pas », pas pour « l'utilisateur comprend ». L'honnêteté, elle, n'est pas un motif fréquent : c'est un jugement.

Et c'est exactement ce qui te reste. Savoir qu'une vérité dort dans le corps de la réponse et exiger qu'on l'affiche, l'IA ne le fera pas à ta place, parce qu'elle ne sait pas ce que ton utilisateur a le droit de savoir. Le mécanisme, tu dois le comprendre assez précisément pour le réclamer. C'est toute la différence entre accepter le code qu'on te propose et voir ce qu'il escamote.

## Ce que je conseille

La règle que j'impose à mes équipes tient en une phrase : un message d'erreur qui ne dit pas à l'utilisateur ce qu'il peut faire n'a pas le droit d'être mergé.

Concrètement, toute erreur 4xx doit faire remonter sa raison jusqu'à l'écran, traduite en langage humain si besoin, mais jamais effacée. Seules les 5xx ont droit au « réessaie plus tard », parce que là, c'est honnêtement tout ce qu'on peut dire. Le test que j'applique en revue : je lis le message à voix haute en me mettant à la place du type coincé un dimanche soir. Si je ne peux rien faire de ce que je viens de lire, c'est un mensonge, on réécrit. Et « erreur technique » est banni chez moi pour tout ce que l'utilisateur a causé et pourrait corriger lui-même.

Ta base de code connaît la vérité bien plus souvent que tu ne le crois. La question n'est pas de la trouver : elle est déjà là, dans la réponse. La question, c'est de décider si tu la dis.

Pour aller sous le capot : le [code de statut HTTP](/definition/code-statut-http), la différence entre [4xx et 5xx](/definition/erreur-4xx-vs-5xx), la [validation côté client ou serveur](/definition/validation), ce qu'est vraiment un [message d'erreur](/definition/message-d-erreur) et un [cas limite](/definition/cas-limite).


Un message d'erreur qui n'affiche pas ce que le système savait, c'est un mensonge par omission. Ce qui se passe entre une validation qui échoue et l'écran que voit ton utilisateur, et la règle que j'impose à mes équipes.

Ne mens pas à tes utilisateurs


Je fais des pizzas à la maison de temps en temps, et pour améliorer mes résultats, je me suis offert un four à pizza professionnel. Il monte à plus de 400°C, c’est génial… sauf que son installation a été un cauchemar. J’ai dû refaire mon installation électrique et changer mon contrat d’énergie parce que ça ne tenait plus.

Résultat ? Mes pizzas ne sont toujours pas aussi bonnes qu’au restaurant.

Le problème ne venait pas du four, mais sûrement de la pâte… que j’achète déjà faite.

## Une obsession pour la technologie au lieu des fondamentaux

Cette situation, aussi absurde soit-elle, est une parfaite analogie de ce qu’on voit souvent en entreprise. On investit dans des outils ultra-puissants, on s’équipe comme les GAFAM… et pourtant, nos résultats ne s’améliorent pas.

Pourquoi ?

* **On sous-estime les vrais besoins** : Un four à 400°C, c’est bien, mais sans une bonne pâte, ça ne sert à rien. De même, Kubernetes, Kafka ou un microservice ultra-scalable n’aideront pas une startup si elle n’a pas encore validé son produit.

*  **On oublie l’impact caché** : Comme mon installation électrique qui a explosé, chaque nouvel outil demande de la formation, de la maintenance et un alignement organisationnel. Une infra surdimensionnée devient vite un frein.

* **On copie sans réfléchir** : On adopte les outils des grands sans se demander pourquoi ils en ont besoin. Spoiler : ce qui fonctionne pour une entreprise de 3000 ingénieurs ne s’applique pas forcément à une équipe de 13 devs.

## L’illusion du minibus : besoin vs envie

On a tendance à envier le minibus du voisin, sans se demander pourquoi il en a besoin.

🚌 Lui : Il a 5 enfants, donc il lui faut un véhicule adapté.

🚗 Toi : Tu vis seul et travailles à distance. Un vélo ou une petite voiture ferait largement l’affaire.

En entreprise, c’est pareil :

* Adoptez des solutions adaptées à votre taille et vos besoins.
* Priorisez les fondamentaux avant de vouloir scaler à tout prix.
* Évitez de surcomplexifier votre stack pour des problèmes qui n’existent pas encore.

## Comment éviter le piège ?

* **Posez-vous la bonne question** : Est-ce que cet outil ou cette technologie répond VRAIMENT à un besoin chez nous, ou est-ce juste parce que “les autres le font” ?

* **Adaptez à votre taille** : Une startup de 10 devs n’a pas besoin de la même stack qu’une scale-up de 500 personnes. Simplicité > Complexité inutile.

* **Commencez par maîtriser les bases** : Avant de vouloir scaler, assurez-vous que votre code, vos process et votre équipe sont solides. Un bon produit et une bonne organisation sont plus importants qu’un outil à la mode.

## Faites des pizzas adaptées à votre cuisine !

Acheter un four ultra-performant ne rendra pas votre pizza meilleure si la pâte est industrielle. De même, adopter des technos de pointe sans maîtriser les bases ne fera pas de votre produit un succès.

* Construisez en fonction de VOS besoins.
* Faites simple avant de vouloir faire complexe.
* Et surtout, ne copiez pas aveuglément les GAFAM.

Après tout, ce n’est pas l’outil qui fait la qualité… c’est la façon dont vous l’utilisez.


Faut-il vraiment copier les GAFAM pour réussir ? Trop souvent, on adopte des outils et technologies surdimensionnés sans répondre à un besoin réel. Découvrez pourquoi il est essentiel de choisir des solutions adaptées à votre équipe et à votre projet, et comment éviter le piège de la complexité inutile.

Arrêtez de copier les GAFAM : adoptez des outils adaptés à vos besoins !


Dans la gestion des incidents, le Post Mortem est devenu une pratique incontournable. Lorsqu’un problème survient, on revient sur ses causes, on analyse ce qui aurait pu être évité et on met en place des actions correctives pour l’avenir. C’est un exercice nécessaire, qui permet de capitaliser sur les erreurs pour améliorer la résilience des systèmes.

Mais faut-il vraiment attendre qu’un projet ou un service tombe en panne pour en tirer des leçons ?

Si nous appliquions la même logique que la médecine légale, nous admettrions qu’une autopsie ne sert qu’à analyser ce qui est déjà perdu. Alors, pourquoi se contenter d’intervenir après la catastrophe, alors qu’on pourrait anticiper et éviter les incidents avant qu’ils ne surviennent ?

Il est temps d’adopter une approche proactive : **le Pre Mortem**.

## Le Pre Mortem : mieux vaut prévenir que guérir

Contrairement au Post Mortem, qui intervient après un incident, le Pre Mortem se déroule en amont. Il s’agit d’un exercice de simulation où l’équipe imagine les scénarios les plus probables d’échec d’un projet, d’un service ou d’une fonctionnalité.

🔍 L’objectif ? Identifier les risques majeurs avant qu’ils ne se matérialisent et élaborer des plans de réponse adaptés.

Un bon Pre Mortem repose sur trois axes :

1. **L’anticipation** : Imaginer les pires scénarios possibles et comprendre leurs déclencheurs.
2. **La prévention** : Définir des mesures pour limiter les risques et éviter les erreurs courantes.
3. **La préparation** : Construire des playbooks d’intervention pour réagir rapidement et efficacement si un problème survient malgré tout.

## Pourquoi intégrer le Pre Mortem dans votre workflow ?

Dans un monde où la rapidité de livraison est cruciale, la gestion des risques est souvent reléguée au second plan. Pourtant, un incident majeur peut coûter bien plus cher qu’une session d’anticipation bien menée.

* **Moins d’incidents critiques** : En identifiant en avance les points faibles, on réduit drastiquement les risques de panne.
* **Une meilleure réactivité** : En ayant déjà préparé des scénarios de crise, on sait exactement comment réagir en cas de problème.
* **Une culture de la résilience** : Les équipes ne subissent plus les incidents, elles les anticipent et les contrôlent.

Même si le Pre Mortem est idéalement réalisé dès la conception d’un projet, il peut aussi être utilisé à tout moment pour sécuriser une application déjà en production. L’essentiel est d’intégrer cette démarche dans les pratiques de l’équipe, au même titre que les revues de code ou les tests automatisés.

## Comment mettre en place un Pre Mortem efficace ?

**1. Organiser une session dédiée**

Réunissez l’équipe projet et consacrez du temps à un brainstorming structuré sur les risques.

**2. Simuler les pires scénarios**

Posez la question : “Imaginons que notre projet échoue. Quels pourraient être les facteurs déclencheurs ?” Listez tous les risques potentiels, du plus probable au plus extrême.

**3. Cartographier les vulnérabilités**

Identifiez les points faibles, les dépendances critiques et les angles morts du projet.

**4. Élaborer des stratégies de prévention**

Pour chaque risque identifié, définissez des actions concrètes pour le réduire ou l’éliminer.

**5. Construire des playbooks d’intervention**

Documentez les procédures de gestion des incidents pour garantir une réponse rapide et efficace en cas de problème.

## Pre Mortem : un changement de d'état d'ésprit essentiel

Dans le développement logiciel, comme dans toute gestion de projet, il est plus rentable d’anticiper que de réparer. Trop souvent, nous sommes enfermés dans une logique de réaction, alors que nous devrions être dans une logique de prévention.

Le Pre Mortem est une approche simple, mais puissante, qui permet aux équipes de prendre le contrôle sur l’avenir de leurs projets au lieu de subir les aléas de la production.

Alors, plutôt que d’attendre l’autopsie d’un projet en échec… Pourquoi ne pas prévoir son avenir dès maintenant ?


Pourquoi attendre qu’un projet échoue pour en tirer des leçons ? Le Pre Mortem permet d’anticiper les risques avant qu’ils ne surviennent, en identifiant les scénarios d’échec et en préparant des stratégies de réponse. Découvrez comment cette approche peut transformer la gestion des incidents et renforcer la résilience de vos projets.

N’attendons pas l’autopsie pour comprendre ce qui ne va pas !


Dans le monde du développement logiciel, on entend souvent la métaphore des LEGO pour illustrer la conception d’une architecture technique. Chaque module, chaque librairie, chaque application s’assemble de manière méthodique, construisant un ensemble robuste et cohérent. Avec les bonnes pièces et un peu de méthode, tout semble réalisable.

Mais si on regarde la réalité en face, notre quotidien ressemble bien plus à une partie de Tetris qu’à une construction soignée en LEGO. Et quand le jeu s’accélère trop vite, il devient vite incontrôlable…

## Le développement en mode Tetris : une course contre la montre

Dans un monde idéal, chaque brique d’un projet logiciel s’intègre harmonieusement, avec une réflexion en amont et des ajustements précis. Dans la vraie vie, c’est une tout autre histoire :

* Les exigences changent constamment, imposant des ajustements imprévus.
* Les délais se raccourcissent, obligeant à empiler rapidement les solutions.
* Les contraintes techniques et organisationnelles s’accumulent, rendant l’assemblage plus complexe.

Tout comme dans Tetris, on ne choisit pas toujours les pièces qui arrivent. Il faut s’adapter en temps réel, trouver la meilleure façon d’intégrer une nouvelle fonctionnalité sans perturber l’existant. Et plus la cadence s’accélère, plus la marge d’erreur se réduit.

## Les dangers d’une accumulation mal maîtrisée

Dans Tetris, une mauvaise décision peut rapidement condamner la partie. Il en va de même en architecture logicielle :

* Empiler trop vite sans réfléchir, c’est prendre le risque d’une architecture instable.
* Les dettes techniques s’accumulent comme des lignes incomplètes, bloquant toute évolution future.
* L’absence de vision à long terme transforme chaque nouvelle brique en un casse-tête, où chaque ajout devient plus compliqué que le précédent.

Quand on enchaîne les choix rapides sans cohérence globale, on finit par s’enfermer dans une structure rigide et chaotique, où la moindre modification devient une prise de tête.

## Prendre le temps de bien jouer : l’importance de l’anticipation

Dans Tetris comme dans le développement logiciel, il ne suffit pas d’empiler les briques au plus vite. Il faut anticiper, organiser et optimiser.

* Ralentir pour mieux structurer : mieux vaut prendre le temps de concevoir une base solide plutôt que de devoir tout reconstruire dans l’urgence.
* Éviter la précipitation : accélérer sans réflexion entraîne plus de problèmes qu’elle n’en résout.
* Penser long terme : une bonne architecture n’est pas qu’une solution immédiate, elle doit être évolutive et maintenable.

## Gagner la partie en jouant intelligemment


La tentation est grande d’aller vite, de livrer rapidement, de s’adapter en temps réel aux contraintes du projet. Mais à force d’accumuler des choix à court terme, on finit par se retrouver bloqué, incapable de faire évoluer l’ensemble sans tout casser.

Un bon développeur ou architecte ne se contente pas d’empiler des briques à toute vitesse : il joue avec stratégie, en anticipant les coups suivants, en gardant une vision d’ensemble, et en construisant un système prêt à durer.

Et parfois, la meilleure décision, c’est simplement d’appuyer sur pause, de réfléchir, et d’accepter que certaines choses prennent du temps. Parce que dans le jeu du développement, ce n’est pas celui qui va le plus vite qui gagne, mais celui qui tient le plus longtemps.


Le développement logiciel ressemble-t-il vraiment à un jeu de LEGO ? Pas si sûr… Entre délais serrés, exigences changeantes et empilement rapide des solutions, notre métier s’apparente plutôt à une partie de Tetris sous pression. Découvrez pourquoi anticiper et structurer son architecture est essentiel pour éviter une accumulation chaotique et garantir la pérennité de vos projets.

L’Architecture et le Développement : une partie de Tetris qui tourne mal ?


J’aime coder, et parce que j’aime coder, il peut m’arriver de me convaincre que telle ou telle fonctionnalité pourrait être super utile, simplement parce que la développer serait assez excitant. Mais n’est-ce pas en réalité une forme de pollution du projet ?

Je suis développeur, le code j’aime ça, je dirais même que j’adore. Plus que ça, c’est la résolution de problèmes à l’aide du code qui me fait palpiter. 

Dans mon métier, au quotidien, c’est plutôt un avantage non négligeable, mais assez fréquemment c’est un poison. Un poison pour la simple et bon raison que si mon plaisir est dans la résolution de problèmes, ça veut également dire que j’aime les problèmes… Comme beaucoup de dev, je joue régulièrement le rôle du pompier pyromane en créant moi-même des problèmes. 

Non, pas des bugs ou des dysfonctionnements, ça n’aurait pas beaucoup de sens, mais des fonctionnalités. Après tout, comment pourrais-je me voir reprocher l’ajout de nouvelles fonctionnalités ? C’est toujours bien d’avoir de nouvelles fonctionnalités dans un système non ?

Dans une grande partie des cas, **non**, ça n’est pas forcément une bonne chose d’ajouter de nouvelles fonctionnalités. Ce n’est pas une bonne idée parce qu’une feature, c’est au minimum :

- De la modélisation / conception
- De l’écriture de code
- De l’écriture de tests
- De l’écriture de documentation
- Très potentiellement de la refacto
- Un risque de régression

En gros, ça prend du temps, de l’énergie, et ça risque même de foutre le bazar dans le projet. 

La question qui se pose ici c’est : est-ce que le jeu en vaut la chandelle ? 

Plus exactement, est-ce que cette nouvelle fonctionnalité a un intérêt fondé autre que simplement venir nourrir mon besoin de résoudre des problèmes ? 

C’est une vraie question. Encore aujourd’hui j’ai stoppé un dev en plein milieu simplement parce que j’ai réalisé qu’il avait des conséquences non négligeables sur mon projet alors que sa seule raison d’être était un « ça pourrait être vachement utile cette fonctionnalité ». 

À vrai dire, dès que cette idée fait surface, il y a potentiellement une embrouille à venir. 

Comme assez souvent, pour se remettre sur les rails, il faut retourner à une certaine forme de radicalité. C’est de cette manière que je tente de plus en plus de prendre en compte deux approches majeures :

- YAGNI
- Philosophie UNIX

## YAGNI

> «*You ain’t gonna need it »*
> 

Pourquoi ajouter cette fonctionnalité alors que tu n’en auras pas besoin ?

Globalement l’idée est de se limiter à ajouter des fonctionnalités qui sont véritablement  nécessaires. C’est assez radical, mais il faut voir ça comme une cure de désintoxication, car il est bien question de toxicité. 

Toxicité parce qu’en plus de faire consommer du temps inutilement, le développement pour l’auto satisfaction risque d’introduire des régressions ou encore de la dette technique. Ça apporte plus de galères qu’autre chose. 

L’idée est donc de se poser une question simple : mon projet a-t-il un besoin vital de cette fonctionnalité ?

L’idée d’un besoin « vital » est centrale ici. Il est vaguement question de se demander si le projet peut simplement exister sans la fonctionnalité en question.

Est-ce que le projet peut vivre sans cette feature ? Alors cette fonctionnalité  n’est absolument pas nécessaire, elle peut être mise à l’écart. 

## Philosophie UNIX

> Fais une chose et fais le bien
> 

C’est probablement un des principes les plus importants de la philosophie UNIX. 

C’est l’idée qu’un programme doit se limiter à un domaine bien précis et ne pas déborder sur un autre. 

Par exemple, le programme `ls` se contente de lister le contenu d’un répertoire. Il possède pas mal d’options, mais se contente de rester dans son domaine : lister le contenu d’un répertoire. 

Il existe bien évidemment des programmes plus complexes comme `ssh` mais concrètement, il se limite à établir une connexion SSH. Il est possible de faire de la redirection de port, d’exécuter une commande à distance, mais il reste dans son domaine : établir une connexion SSH. 

Vous voulez copier un fichier via SSH ?

Pas de soucis, le programme `scp` est là pour ça, mais ça n’est pas une fonctionnalité du programme `ssh`. 

## Attendre un besoin signifie-t-il ne plus anticiper ?

C’est exactement à ce moment que nous pouvons être tentés de retomber dans la création de features non sollicités et malheureusement, je ne connais pas d’acronyme faisant référence à une quelconque philosophie.

Ici, pas de règle, simplement se faire confiance à soi-même. Faire confiance à son expérience, à sa connaissance du métier / produit.

Les principes comme YAGNI ne permettent en réalité que d’apprendre à se maîtriser soi-même. Il n’est aucunement question de règles à suivre de manière dogmatique, mais plutôt d’outils pour alimenter son auto discipline.

J’aime coder, et parce que j’aime coder, il peut m’arriver de me convaincre que telle ou telle fonctionnalité pourrait être super utile, simplement parce que la développer serait assez excitant. Mais n’est-ce pas en réalité une forme de pollution du projet ?

Et si je foutais cette feature la poubelle ?

Dans ce billet nous allons revenir sur l’aversion que peuvent avoir les développeurs envers les recruteurs et sur la nécessité de les voir comme des partenaires plutôt que comme des ennemies. 

Désolé pour toi Camarade recruteur si tu passes par là, ça peut sembler très cru, mais autant être très clair et éviter de tourner autour du pot.

## Pourquoi les développeurs détestent-ils les recruteurs ?

Ce n’est ni un secret, ni un tabou. Les développeurs ont tendance à mépriser les recruteurs et soyons honnêtes, pendant longtemps il y a eu des raisons plus que valables d’adopter cette posture. 

Entre la recherche du mouton à 5 pattes, du « Javascript Ninja » ou encore de développeur Java parce que sur le profil il y a écrit Javascript, les prises de contact automatisées par mail ou LinkedIn souvent à côté de la plaque, la difficulté à obtenir des informations de base sur la mission avant un éventuel entretien téléphonique, … Les relations peuvent être assez compliquées. 

Globalement nous avons tendance à avoir le sentiment d’être des marchandises que les recruteurs souhaitent exploiter sans même chercher à comprendre ce que nous faisons ni même ce que nous sommes. 

Il faut cependant être totalement honnête, les recruteurs charcutiers ne sont pas la totalité des recruteurs. Il y a fort heureusement beaucoup d’excellents recruteurs avec une véritable connaissance de la tech et possédant une véritable approche humaine (oui bon ça veut tout et rien dire cette formule, je l’admets volontiers).

## Et si nous devions simplement les considérer comme des apporteurs d’affaire ?

Que nous aimions les recruteurs ou non, qu’ils nous aiment ou non, il ne faut surtout pas perdre de vue le principal : nous faisons du business.

Si dans le contexte d’un poste de salarié nous pourrions avoir une vision totalement différente, pour ce qui est du freelancing, il faut garder à l’esprit que les recruteurs sont des apporteurs d’affaire, des liens entre nous et les clients finaux.

Quand un commercial vient te proposer une mission en régie sur 6 mois avec un TJM de 650€, c’est avant tout un contrat d’environs 80k€ qui t’est proposé. C’est loin d’être négligeable, d’autant plus que ce contrat de 80k€, tu n’aurais probablement pas pu l’obtenir autrement.

Rembobinons.

Comment ça le contrat n’aurait pas pu être obtenu autrement ? 

Il est capital de savoir que pour beaucoup d’entreprises, notamment des grandes entreprises et grands groupes, il faut être référencé comme fournisseur pour pouvoir faire de la prestation. Pour être référencé, il faut répondre à un cahier des charges qui ne pourrait juste pas être défendu par un freelance seul. C’est ainsi que pour pouvoir faire des missions dans certaines entreprises, il n’y a pas le choix : il faut passer par un tiers.

Dans ce contexte, quoi de mieux que d’avoir des partenaires qui viennent te proposer des missions ?

## Comment les free pourraient reprendre l’ascendant

Maintenant que nous avons dressé un petit topo sur le sujet, prenons un instant pour imaginer comment nous, freelances, pourrions reprendre la main sur cette relation qui a souvent tendance à nous écraser un peu.

Ce que je souhaite détailler ici, c’est la mise ne place d’un document qui pourra être partagé directement avec les recruteurs lorsqu’ils prennent contact.

Ce document peut être un PDF ou une page en ligne. En ce qui me concerne, j’ai mis ça sur Notion, sous la forme d’une page publique. De cette manière je peux la partager facilement 

### Informations essentielles

Dans un premier temps, le document commence par les informations essentielles : 

- TJM
- Localisation
- Télétravail (fréquence, si concerné)
- Durée de mission souhaité
- Liens utiles (Github, Linkedin, page Malt, …)

L’idée 

### Critères de mission

Ensuite, définissons clairement ce que nous souhaitons et ne souhaitons pas.

- Quel type d’industrie souhaité ou refusé ?
- Quel type de mission, stack, responsabilité, … ?
- Quelle localisation, fréquence de remote ?
- Quel TJM ?
- …

Bref, l’idée ici est de lister très clairement ce que l’ont veut et ne veut pas. Attention, les nuances sont importantes. Il y a ce que l’ont veut et ce que l’ont souhaite, ce que l’ont ne souhaite pas et ce que l’ont refuse.

Il est également utile de préciser ce sur quoi il est possible de négocier, par exemple : 

> Sur site maximum 2x par semaine (idéalement 1x ou roulement 2x toutes les deux semaines).
Possible d’être sur site un peu plus longtemps au démarrage de la mission.
> 

Ensuite, il est nécessaire de proposer une synthèse de son profile, idéalement en un paragraphe. Les expériences détaillées viennent à la fin du document, par besoin de noyer le lecteur dans trop d’information dès le départ.  

### Prise de rendez-vous

Ce document, finalement, c’est un tunnel de vente. Un tunnel de vente doit mener à une action. Dans notre cas, l’action c’est une prise de rendez-vous. 

Vous pouvez inclure le widget d’un outil comme Calendly qui permettra de gérer tout le processus de prise de rendez-vous. Concrètement, vous liez votre agenda à l’outil pour empêcher la prise de rendez-vous à des moments où vous n’êtes pas dispo. Il est également possible (nécessaire) de déterminer des créneaux pour les prises de rendez-vous. Par exemple, le 10h a 11h et de 16h à 17h du mardi au jeudi. 

Il existe encore pas mal de fonctionnalités comme la création de visio automatique, le rappel de rdv aux participants ou encore l’ajout de périodes impossible à réserver avant et après un événement. 

De cette manière, il est possible de laisser au recruteur la possibilité de poser un rendez-vous de 10/15 minutes à un moment qui vous convient. 

### CV

C’est la fin du document. Il faut, c’est à ce moment que le contenu le plus imposant peut être placé, comme une forme d’annexe. 

Bien que le CV soit proposé au téléchargement au début du document, il peut être utile de laisser la possibilité au recruteur de le voir directement dans le document sans avoir à télécharger quoi que ce soit.


Dans ce billet nous allons revenir sur l’aversion qu’ont les développeurs envers les recruteurs et sur la nécessité de les voir comme des partenaires plutôt que comme des ennemies.  Nous terminerons par une réflexion sur le rôle des recruteurs et sur l’évolution de celui-ci dans les années à venir. 

L'autodidacte