Les erreurs d’UX qui frustrent vos utilisateurs (et comment les éviter)


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. 

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


Ils sont là, bien cachés, prêts à nous bondir sur le coin du nez avec leurs grosses erreurs rouges venant défigurer la console de notre navigateur.

Je parle des entêtes CORS, ces fameux entêtes qui viennent vous rappeler que non, tout ne roule pas systématiquement sur des roulettes. 

Et si je vous disais que les CORS étaient là en réalité pour vous protéger ? 

## Les cookies laissent des miettes

Avant de rentrer dans quoi que ce soit comme explication, il est fondamental de revenir sur ce qui est un des plus gros risques dans un navigateur : les cookies. 

Alors non, dans les faits, les cookies ne représentent pas le moindre danger, cependant il faut savoir que chaque requête HTTP contient systématiquement les cookies liés au domaine appelé. 

Cela signifie que si je fais une requête sur [https://mabanque.fr/solde](https://mabanque.fr/solde), tous les cookies liés à ce domaine présents sur mon navigateur seront transmis dans la requête.

C’est de cette manière que les cookies transitent, lorsqu’ils ont été déposés sur le navigateur, ils sont automatiquement intégrés aux requêtes sortantes.

C’est d’ailleurs pour cette raison que vous pouvez voir les domaines associés aux cookies dans votre console. 

 

![Capture d’écran 2022-10-24 à 20.55.13.png](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/0c163522-08e9-4d18-a816-9e90ab1131f0/Capture_decran_2022-10-24_a_20.55.13.png)

Lorsque nous nous authentifions sur un site, généralement le site va déposer un cookie contenant un identifiant de session, voir un token. De cette manière, lorsque nous effectuons des requêtes vers le site en question, il peut récupérer l’identifiant de la session contenue dans les cookies pour s’assurer que l’utilisateur est bien connecté et ainsi lui donner accès à la ressource demandée.

![..](https://mermaid.ink/svg/eyJjb2RlIjoic2VxdWVuY2VEaWFncmFtXG4gICAgQnJvd3Nlci0-PitBUEk6IEF1dGhlbnRpZmljYXRpb25cbiAgICBBUEktPj4tQnJvd3NlcjogSUQgZGUgc2Vzc2lvbiAodmlhIHVuIGNvb2tpZSlcbiAgICBCcm93c2VyLT4-K0FQSTogUmVxdcOqdGUgcXVlbGNvbnF1ZSAoaW5jbHVhbnQgbGUgY29va2llIGF2ZWMgSUQgZGUgc2Vzc2lvbilcbiAgICBBUEktPj4tQnJvd3NlcjogSmUgdCdhaSByZWNvbm51LCBkZW1hbmRlIG1vaSBjZSBxdWUgdHUgdmV1eCAiLCJtZXJtYWlkIjp7InRoZW1lIjoiZGVmYXVsdCJ9LCJ1cGRhdGVFZGl0b3IiOmZhbHNlfQ)

C’est donc à l’aide des cookies que nous pouvons rester connectés à un site internet. 

## Requêtes Cross Domain et récupération d’informations sensibles

Imaginons un scénario basique dans un monde où la sécurité ne serait pas prise en compte.

Nous nous rendons sur un site quelconque sans savoir que celui-ci a décidé de nous dépouiller. Lorsque nous arrivons sur le site, il charge du Javascript qui va faire des requêtes vers notre banque. Cette requête va tenter de récupérer le solde du compte par exemple, voir des informations nettement plus sensibles.

Il est à noter que je me suis connecté récemment à ma banque en ligne, j’ai alors encore des cookies qui contiennent les informations de ma session.

Le site de l’attaquant faisant une requête vers ma banque, celle-ci contient tous les cookies nécessaires pour que ma banque réponde favorablement à la requête. 

De cette manière, l’attaquant peut faire tous les appels API qu’il souhaite en exploitant la présence de cookies sur notre navigateur.

## Comment empêcher les requêtes Cross Domain ?

Il est important ici de prendre en compte une restriction non négligeable : de base, les navigateurs refusent les requêtes vers un autre domaine que celui sur lequel vous êtes.

Concrètement, je suis sur le site [https://uneembrouile.com](https://uneembrouile.com) qui tente de faire une requête AJAX vers [https://mabanque.fr](http://mabanque.fr), à moins que l’API mabanque.fr ait explicitement autorisé le domaine [uneembrouille.com](http://uneembrouille.com) à faire des requêtes, le navigateur va gentiment mettre un stop à la requête en affichant une magnifique erreur : 

![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/466a8a86-0d46-40cf-bc23-da830bccc5ba/Untitled.png)

Avec ce mode de fonctionnement, les appels vers des API tierces sont bloqués par défaut et le site qui voulait initialement me dépouiller n’a plus qu’une chose à faire : rester en chien.

Mais pour le coup, comment permettre à une application de faire des requêtes sur un autre domaine ? 

C’est ici que CORS intervient en permettant de déclarer explicitement quel site peut consommer les ressources d’un serveur. 

## Comment fonctionne CORS ?

Au fait, nous avons parlé de la signification de CORS ? 

> *Cross-Origin Resource Sharing*
> 

C‘est un mécanisme qui se base sur des entêtes (ou headers) contenu dans les réponses des API indiquant si le domaine appelant peut accéder, ou non, à la ressource demandée.

Globalement le mode de fonctionnement est assez basique. Comme nous l’avons vu précédemment, de base, le navigateur bloque toutes les requêtes vers un autre domaine que celui de la page en cours de consultation. Pour pouvoir appeler un domaine tiers, il faut nécessairement qu’il nous y autorise explicitement. 

 

Pour autoriser, c’est assez simple, le serveur sur l’autre domaine doit répondre avec au minimum une entête `Access-Control-Allow-Origin` contenant soit le domaine appelant, soit un wildcard (*). 

Imaginons maintenant un nouveau scénario. 

Je me rends sur le site [https://pasdembrouille.fr/](https://pasdembrouille.fr/) et celui-ci souhaite faire des requêtes vers [https://unsitesensible.fr/](https://unsitesensible.fr/).

Normalement, les requêtes devraient être bloquées par le navigateur, cependant, les deux sites travaillent ensemble et [https://unsitesensible.fr/](https://unsitesensible.fr/) répond aux requêtes de [pasdembrouille.fr](http://pasdembrouille.fr) avec ce header en particulier : 

`Access-Control-Allow-Origin: pasdembrouille.fr`

Avec ce header, le navigateur comprend que la requête est légitime. Il la laisse passer.

Ici il est à noter que ce mode de fonctionnement permet de déterminer explicitement quels sont les sites (domaines) pouvant utiliser l’API. Utiliser un wildcard (`*`) c’est rendre Open Bar son API. Dans certains cas c’est souhaité, mais il est nécessaire de bien comprendre que l’utilisation d’un wildcard fait sauter ce qui est à l’origine une sécurité. 

### Requête de Preflight

### Requêtes concernées par CORS

Ce ne sont pas toutes les requêtes qui sont concernées. À vrai dire, ce ne sont que les requêtes initiées par AJAX. 

Les autres requêtes comme le chargement d’images, de feuilles de style ou même de scripts, peuvent se faire Cross Domain sans problème. 

À vrai dire elles ne posent pas trop de problèmes. Il y a bien les attaques CSRF mais c’est un autre sujet, que peut-être nous traiterons dans un prochain article. 

## Comment contourner CORS ?

Soyons parfaitement clairs, il est possible de contourner les restrictions mais pas de récupérer les cookies pour le domaine de l’API cible. 

Les deux solutions présentées juste après sont totalement différentes. 

La première, JSONP, doit être mise en place par le fournisseur de l’API. Généralement cette solution est proposée pour des ressources accessible en lecture seule. 

Quant à la seconde, elle est mise en place par celui qui souhaite consommer l’API sans avoir la possibilité de modifier l’API elle-même. 

### JSONP

JSONP ou *JSON with Padding*, est une solution permettant d’appeler une API en exploitant l’absence de restriction sur le chargement de script JS. 

Dans les faits, il est nécessaire de déclarer une fonction qui recevra la réponse de l’API dans le scope global

### Utilisation d’un proxy intermédiaire

Vous avez besoin de faire des appels à une API publique ne proposant pas de headers vous autorisant à effectuer des requêtes ?

Une solution est l’utilisation d’un Proxy entre la page web et l’API. 

Un Proxy n’est rien d’autre qu’un serveur web qui transmet les requêtes qui lui sont faites a un autre serveur (un API plus précisément) et retour la réponse du serveur au client. 

[schema]

Comme les restrictions CORS n'ont lieux que dans un navigateur, si c’est un server qui appelle l’API, le problème ne se pose plus.

Ils sont là, bien cachés, prêts à nous bondir sur le coin du nez avec leurs grosses erreurs rouges venant défigurer la console de notre navigateur. Je parle des entêtes CORS, ces fameux entêtes qui viennent vous rappeler que non, tout ne roule pas systématiquement sur des roulettes. "

L'autodidacte

Archive

2025

2022