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


Je fais des pizzas maison de temps en temps, et pour progresser, je me suis offert un four à pizza professionnel. Il monte à plus de 400°C. Génial, sauf que l'installer a été un cauchemar : j'ai dû refaire mon tableau électrique et changer de contrat d'énergie, parce que ça ne tenait plus. Et après tout ça, mes pizzas n'étaient toujours pas meilleures qu'au restaurant.

Le four n'y était pour rien. Le problème, c'était la pâte. Que j'achète déjà faite.

Cette histoire un peu bête est la photographie exacte de ce qu'on fait en entreprise. On investit dans l'outil le plus puissant du marché, on se grée comme les GAFAM, et les résultats ne bougent pas. Parce qu'un outil de pointe ne répare pas un fondamental bancal. Il le rend juste plus cher.

## Copier la cuisine des géants

Kubernetes, Kafka, le microservice ultra-scalable : ce sont des fours à 400°C. Ils résolvent des problèmes réels, mais des problèmes de gens qui ont trois mille ingénieurs et des milliards de requêtes. Les adopter dans une équipe de treize devs qui cherche encore son produit, c'est brancher le four avant d'avoir appris à faire la pâte.

Et comme mon installation électrique, chaque outil surdimensionné a un coût caché qu'on découvre après l'achat. Il faut le former, le maintenir, aligner l'équipe et l'organisation autour. Ce que tu croyais être un accélérateur devient un poids : tu passes plus de temps à entretenir ta stack qu'à livrer ce pour quoi tes clients te paient. La complexité que tu t'imposes pour des problèmes que tu n'as pas encore te ralentit sur les problèmes que tu as vraiment.

Au fond, c'est une confusion entre le besoin et l'envie. Tu envies le grand monospace du voisin sans te demander pourquoi il l'a : lui a cinq enfants, toi tu vis seul et tu travailles à distance, un vélo suffirait. En entreprise, c'est pareil. Tu regardes la stack d'une boîte de cinq cents personnes en oubliant que c'est sa taille et ses contraintes qui l'ont dictée, pas son génie. Ce qui la sauve, elle, te noierait, toi.

## Ce que l'IA change

L'assistant rend le piège encore plus tentant. Demande-lui une architecture, il te génère la stack complète des géants sans broncher : le microservice, la file de messages, l'orchestrateur, tout, d'un coup. C'est justement là le danger. La machine sait produire la sophistication ; elle ne sait pas si tu en as besoin. Décider de ce qui est juste pour ta taille, ton équipe et ton moment, c'est le jugement qui te reste, et il n'a jamais eu autant de valeur, parce que le surdimensionnement, lui, n'a jamais été aussi facile à générer.

## Ce que je te conseille

Avant d'adopter un outil, pose-toi une seule question : est-ce qu'il résout un problème qu'on a vraiment, maintenant, ou est-ce qu'on le prend parce que les autres l'ont ? Si tu n'arrives pas à nommer le problème, tu n'as pas besoin de l'outil. Maîtrise tes fondamentaux d'abord, ton code, tes process, ton équipe, avant de vouloir passer à l'échelle quoi que ce soit. Et dimensionne la solution à ta cuisine, pas à celle du restaurant trois étoiles d'à côté.

Un four à 400°C ne sauvera jamais une pâte industrielle. Ce n'est pas l'outil qui fait la qualité, c'est ce que tu sais en faire.


Je me suis offert un four à pizza à 400°C. Mes pizzas ne sont pas meilleures pour autant, parce que le vrai problème, c'était la pâte. La même erreur qu'on fait en copiant la stack des GAFAM sans avoir leurs problèmes.

Ce n'est pas le four, c'est la pâte


À la fin d'un post mortem, il y a presque toujours la petite phrase. Quelqu'un finit par la lâcher, à voix basse : « celui-là, je le sentais venir. » Et tout le monde hoche la tête, parce qu'au fond, plusieurs le sentaient venir. Le savoir existait. Il était là, dans la salle, avant même que ça casse. Il n'est simplement jamais sorti à temps.

C'est ça, le vrai gâchis d'un incident : la plupart du temps, quelqu'un savait.

Le post mortem est devenu un réflexe sain. Après la panne, on revient sur les causes, on tire les leçons, on corrige. C'est nécessaire. Mais c'est une autopsie : ça n'explique bien que ce qui est déjà mort. La question intéressante, c'est de savoir pourquoi on attend le cadavre pour poser des questions qu'on aurait pu poser avant.

## Faire l'autopsie avant le décès

Le pré-mortem, c'est exactement ça : l'autopsie, jouée à l'avance. Tu réunis l'équipe au début d'un projet, et au lieu de demander « quels sont les risques ? » (question à laquelle personne ne répond vraiment), tu poses celle-ci : « on est dans six mois, le projet est un fiasco complet. Qu'est-ce qui l'a tué ? »

L'inversion n'est pas un gadget. « Liste les risques », c'est une question qui met les gens sur la défensive : personne ne veut jouer les oiseaux de mauvais augure. « Le projet a échoué, raconte-moi pourquoi », ça libère la parole, parce que tu ne prédis plus une catastrophe, tu en expliques une déjà posée sur la table. D'un coup, les craintes que chacun gardait pour lui sortent. Le « de toute façon, cette dépendance-là va nous lâcher », le « personne ne comprend vraiment ce module », le « on n'aura jamais le temps de tester ce cas ». Tout ce qui, dans un post mortem, aurait commencé par « je le sentais venir ».

Ensuite, c'est mécanique. Chaque scénario de mort devient une ligne d'action : ce qu'on désamorce tout de suite, ce qu'on surveille, ce pour quoi on prépare un plan B. Tu ne supprimes pas le risque, tu refuses juste d'être surpris par lui.

## Ce que l'IA n'anticipe pas

Demande à un assistant la liste des risques d'un projet, il t'en sort trente, propres, génériques : la dette, les délais, le turnover, la sécurité. Utile comme aide-mémoire, et parfaitement inutile là où ça compte. Parce que le risque qui va vraiment te tuer n'est pas le générique, c'est le spécifique : la dépendance que ton équipe redoute sans oser le dire, le bout de système que tenait la personne qui vient de partir. Ça, ce n'est écrit nulle part. C'est dans la tête des gens, et seule une question bien posée le fait sortir. Le pré-mortem, c'est cette question.

## Ce que je te conseille

Fais-en un au démarrage de chaque projet qui compte : une heure, pas plus. Et refais-en un quand tu sens l'équipe tendue sans savoir pourquoi, parce que cette tension, souvent, c'est un pré-mortem qui demande à avoir lieu. Note chaque « je le sentais venir » comme un risque à traiter maintenant, pas comme une phrase à ressortir le jour de l'autopsie.

Il est toujours moins cher d'imaginer la mort d'un projet que de la constater. Autant faire l'autopsie tant qu'il est encore vivant.

Ce satellite fait partie du dossier [Le modèle du gruyère](/dossier/gruyere), sur la défense en profondeur.


À la fin d'un post mortem, quelqu'un finit toujours par lâcher « je le sentais venir ». Le savoir était là avant le crash. Le pré-mortem, c'est poser la question avant, quand on peut encore agir.

La panne qu'on avait tous sentie venir


Tu cases une fonctionnalité en catastrophe pour tenir la date. Ça rentre, ça marche, tu passes à la suite. Sauf que la suivante est deux fois plus dure à poser : la place où elle devait aller, tu l'as bouchée la veille avec la précédente. Et trois features plus loin, la moindre modification t'oblige à déplacer la moitié de l'existant. Tu n'es plus en train de construire. Tu es en train de perdre une partie de Tetris.

On aime se raconter que développer, c'est du LEGO. Des briques nettes, un plan, tu assembles à ton rythme un ensemble propre et cohérent. C'est l'image qu'on vend dans les conférences. C'est aussi un mensonge réconfortant.

## Le vrai jeu, c'est Tetris

Le LEGO, tu choisis tes pièces, tu as tout ton temps, tu peux défaire et refaire. Rien à voir avec ton quotidien. Dans la vraie vie, les exigences changent en cours de route, les délais se resserrent, et surtout tu ne choisis pas les pièces qui tombent. Une demande arrive, sa forme est imposée, et tu dois la caser dans l'existant sans casser ce qui tourne. Exactement Tetris : tu subis la pièce, tu décides seulement où la poser, et l'horloge accélère.

Et Tetris pardonne mal. Chaque pièce mal placée dans l'urgence laisse un trou, et les trous, ce sont tes dettes : des lignes jamais complétées qui bloquent tout ce qui vient au-dessus. Empile assez vite sans réfléchir, et tu te retrouves avec une structure haute, rigide, où poser la brique suivante relève du casse-tête. La partie ne se perd pas d'un coup. Elle se perd trou par trou, jusqu'au jour où plus rien ne rentre.

## La seule touche qui compte : pause

La tentation, sous pression, c'est d'accélérer : livrer, s'adapter, empiler. C'est le réflexe qui perd la partie. Le bon joueur ne pose pas ses pièces plus vite, il regarde la suivante avant de poser celle du moment. Il garde une vision d'ensemble, il complète ses lignes au lieu de boucher des trous, et il sait qu'appuyer sur pause pour réfléchir n'est pas du temps perdu : c'est ce qui l'empêche de tout reconstruire dans trois semaines.

## Ce que l'IA change

L'IA a mis Tetris en accéléré. Elle génère des pièces plus vite que jamais : tu obtiens en dix minutes ce qui t'aurait pris deux jours. Le problème, c'est que le jeu n'a jamais consisté à produire des pièces, mais à décider où les poser. Générer plus vite ne t'aide pas si tu bouches tes trous plus vite. Ce que la machine ne fait pas, c'est regarder la partie d'en haut et te dire « pas là ». La vision d'ensemble, l'anticipation des coups suivants, c'est ce qui te reste, et c'est ce qui sépare celui qui tient de celui qui sature.

## Ce que je te conseille

Avant de poser une pièce en urgence, prends la seconde qui coûte : est-ce que je complète une ligne, ou est-ce que je crée un trou que je paierai plus tard ? Tu n'auras pas toujours le luxe de bien placer, la pression est réelle. Mais sache au moins quand tu crées un trou, et garde une trace de là où il est. Dans ce jeu, ce n'est pas celui qui pose le plus vite qui gagne. C'est celui qui tient le plus longtemps sans que tout s'écroule.


On aime comparer l'architecture logicielle à un jeu de LEGO : des briques propres qu'on assemble à loisir. La vérité ressemble bien plus à une partie de Tetris sous pression, où tu ne choisis pas les pièces et où l'accumulation finit par tout bloquer.

Tu ne construis pas en LEGO, tu joues à Tetris


Récemment, j'ai arrêté un développement en plein milieu. Pas parce qu'il était bogué : il marchait très bien. Je l'ai arrêté parce que j'ai réalisé que sa seule raison d'exister, c'était une phrase que je m'étais dite à moi-même : « ça pourrait être vachement utile, cette fonctionnalité. » Et cette phrase, chez moi, est presque toujours le début des ennuis.

J'aime coder. Plus exactement, j'aime résoudre des problèmes avec du code, c'est ce qui me fait palpiter. Au quotidien, c'est un avantage. C'est aussi un poison : si mon plaisir est de résoudre des problèmes, alors quelque part, j'aime les problèmes. Et comme beaucoup de devs, il m'arrive de jouer au pompier pyromane, en créant moi-même ceux que je résoudrai ensuite. Pas des bugs, ça n'aurait pas de sens. Des fonctionnalités.

Après tout, qui pourrait me reprocher d'ajouter des fonctionnalités ? C'est toujours bien, une fonctionnalité de plus, non ? Eh bien non. La plupart du temps, non.

## Ce que coûte une feature que personne n'a demandée

Une fonctionnalité, ce n'est jamais juste du code. C'est de la conception, du code, des tests, de la doc, souvent de la refacto pour l'intégrer, et un risque de régression sur tout ce qui marchait avant. Ça prend du temps, ça prend de l'énergie, et ça peut foutre le bazar dans un projet sain. Tout ça pour une idée dont la seule justification est qu'elle serait « excitante à développer ».

La vraie question, à chaque fois, c'est : est-ce que le jeu en vaut la chandelle ? Ou plus honnêtement : est-ce que cette fonctionnalité a un intérêt réel, autre que nourrir mon envie de coder ? Dès que la réponse traîne, il y a une embrouille en approche. Pour me tenir, je m'appuie sur deux garde-fous un peu radicaux.

## YAGNI

*You ain't gonna need it.* Pourquoi ajouter ce dont tu n'auras pas besoin ? L'idée est de se limiter aux fonctionnalités vraiment nécessaires. C'est radical, mais c'est une cure de désintox, parce qu'il est bien question de toxicité : le développement pour l'auto-satisfaction consomme du temps, introduit des régressions, alourdit la dette. Il apporte plus de galères qu'autre chose.

Le test tient en une question : mon projet peut-il vivre sans cette feature ? S'il le peut, elle n'est pas nécessaire. Elle attend, ou elle dégage.

## La philosophie UNIX

*Fais une seule chose, et fais-la bien.* Un programme doit rester dans son domaine et ne pas déborder. `ls` liste le contenu d'un répertoire, point, même s'il a mille options. `ssh` ouvre une connexion, rien d'autre. Tu veux copier un fichier à travers SSH ? `scp` est là pour ça, ce n'est pas le boulot de `ssh`. La force de ces outils, c'est précisément ce qu'ils refusent de faire.

## Attendre le besoin, est-ce arrêter d'anticiper ?

C'est le piège inverse, et c'est là que la tentation de recréer des features non sollicitées revient. Sauf qu'ici, pas d'acronyme, pas de règle. Juste se faire confiance : à son expérience, à sa connaissance du produit. YAGNI et les autres ne sont pas des dogmes à appliquer aveuglément, ce sont des outils pour apprendre à se maîtriser soi-même.

## Ce que l'IA change

Et elle change beaucoup, ici. Avant, l'envie de coder une feature inutile se heurtait au moins à son coût : des jours de boulot, ça refroidit. L'IA vient de faire sauter ce garde-fou. Elle te génère la fonctionnalité tentante en quelques minutes, presque gratuitement. Le frein naturel a disparu. Ce qui veut dire que la seule chose qui protège encore ton projet de l'accumulation, c'est ta décision de ne pas la construire. Savoir dire non à une feature n'a jamais autant compté que depuis qu'il est devenu si facile de dire oui.

## Le meilleur commit est parfois celui qu'on ne fait pas

Le meilleur code que j'aie écrit récemment, c'est celui que je n'ai pas écrit. La prochaine fois qu'une idée te fait de l'œil juste parce qu'elle serait sympa à développer, pose-toi la seule question qui compte : le projet en a-t-il vraiment besoin ? Si tu hésites, tu as ta réponse. Foutre la feature à la poubelle, c'est parfois le meilleur commit de la journée.


J'aime coder, et parce que j'aime coder, il m'arrive de me convaincre qu'une fonctionnalité serait super utile, simplement parce que la développer serait excitant. 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. 

En tant que Freelance, faut-il haïr les recruteurs ?


Ils sont là, tapis dans la console, prêts à te sauter au visage avec leurs grosses erreurs rouges dès que tu tentes un appel un peu ambitieux. Les fameux en-têtes CORS, ceux qui te rappellent que non, tout ne roule pas toujours tout seul. Et si je te disais qu'en réalité, ils ne t'en veulent pas ? Qu'ils sont là pour protéger quelqu'un, et que ce quelqu'un, c'est ton utilisateur ?

## Chaque requête traîne tes cookies

Pour comprendre CORS, il faut d'abord un fait tout bête. Quand ton navigateur fait une requête vers un domaine, il y joint automatiquement tous les cookies qu'il possède pour ce domaine. Tu appelles `mabanque.fr`, et le cookie de session que ta banque a déposé chez toi part avec la requête, sans que tu fasses quoi que ce soit. C'est même comme ça que tu restes connecté : le cookie voyage seul, le serveur le lit, il te reconnaît.

Pratique. Et un peu terrifiant, si on y réfléchit une seconde.

## Le scénario où on te fait les poches

Imagine un web sans aucune protection. Tu t'es connecté à ta banque ce matin, tu as donc encore ton cookie de session bien au chaud. Puis tu visites un site quelconque, qui a décidé de te dépouiller. Ce site charge du JavaScript qui, en douce, lance une requête vers `mabanque.fr/solde`.

Comme cette requête part vers le domaine de ta banque, elle emporte, automatiquement, ton cookie de session. Ta banque reçoit une requête parfaitement authentifiée, te reconnaît, et répond avec ton solde. Le site malveillant n'a jamais vu ni ton mot de passe ni ton cookie : il a juste profité du fait que ton navigateur, lui, les avait. Et il pourrait enchaîner tous les appels qu'il veut.

C'est exactement ce que le navigateur refuse de laisser arriver.

## La règle par défaut : on ne parle pas aux étrangers

Par défaut, un navigateur bloque les requêtes JavaScript vers un autre domaine que celui de la page en cours. Tu es sur `uneembrouille.com`, tu tentes un appel vers `mabanque.fr` : le navigateur met le holà et t'affiche la fameuse erreur rouge. C'est la politique de même origine, et cette erreur CORS que tu maudis, c'est elle qui parle.

Autrement dit, le rouge dans ta console n'est pas un bug. C'est le système qui fait son travail : empêcher, par défaut, n'importe quel site de se servir de la session bancaire ouverte dans ton autre onglet.

CORS, c'est simplement le mécanisme qui permet de faire une exception, proprement. Si une API veut autoriser un domaine précis à l'appeler, elle répond avec un en-tête, `Access-Control-Allow-Origin`, contenant ce domaine. Le navigateur voit l'autorisation explicite, et laisse passer. Deux sites qui travaillent ensemble s'entendent ainsi, sans ouvrir la porte à toute la rue.

## Le « correctif » qui désarme le garde du corps

Et c'est là que ça dérape, en général. Face à l'erreur rouge, la tentation est de la faire taire au plus vite. La façon la plus rapide : répondre `Access-Control-Allow-Origin: *`. L'étoile, ça veut dire « n'importe quel domaine peut m'appeler ». L'erreur disparaît, tu es content, tu passes à autre chose.

Sauf que tu viens de retirer la sécurité que CORS mettait en place. Pour une API vraiment publique et sans cookie, l'étoile est légitime. Mais la coller pour éteindre un voyant rouge sans comprendre ce qu'il protégeait, c'est débrancher le garde du corps parce qu'il t'a demandé ta pièce d'identité.

## Ce que l'IA te souffle un peu trop vite

Demande à un assistant de régler ton erreur CORS, et il ira souvent au plus court : mets une étoile, ou passe par un proxy qui contourne la restriction côté serveur. Ça marche, l'erreur s'en va. Mais la question qu'il ne pose pas, parce qu'il ne connaît pas ton contexte, c'est : cette porte, ai-je le droit de l'ouvrir aussi grand ? Y a-t-il, derrière, des cookies, des données sensibles, une session ? Ce jugement sur ce que tu protèges et pour qui ne se génère pas. La machine sait faire disparaître le rouge. Savoir si tu en as le droit, ça reste à toi.

## Ce que je te conseille

Quand tu tombes sur une erreur CORS, ne cherche pas d'abord à la faire taire. Demande-toi ce que le navigateur est en train de protéger. La plupart du temps, il fait exactement son boulot, et le bon correctif n'est pas de retirer le mur : c'est d'autoriser, côté serveur, le domaine précis qui en a besoin. L'étoile, garde-la pour les API réellement publiques, et en connaissance de cause.

Le rouge dans ta console n'est pas ton ennemi. C'est souvent le seul, dans l'histoire, qui se soucie de ton utilisateur pendant que tu te bats avec ta requête.

En marge du voyage d'une URL, dans le dossier [Navigateur](/dossier/browser). Le vocabulaire : les [CORS](/definition/cors) et le [cookie](/definition/cookie).


Ils sont tapis dans la console, prêts à te sauter au visage avec leurs grosses erreurs rouges. Et si les CORS ne t'en voulaient pas ? S'ils étaient là pour protéger, pas toi, mais ton utilisateur, de sa propre session ouverte dans l'onglet d'à côté ?

L'autodidacte

Toutes les publications

Ce n'est pas le four, c'est la pâte

La panne qu'on avait tous sentie venir

Tu ne construis pas en LEGO, tu joues à Tetris

Et si je foutais cette feature à la poubelle ?

En tant que Freelance, faut-il haïr les recruteurs ?

Pourquoi les CORS veulent faire sauter ton navigateur ?