DEV Community: Gabin ✨✨

Guide : simuler revenu freelance vs salaire

Gabin ✨✨ — Thu, 30 Mar 2023 13:47:14 +0000

Calculer son tarif en freelance est l'une des premières étapes quand on se lance. Ce guide propose une formule, des références et des outils qui t'aideront à faire un choix éduqué.

Étape 1 : regarde ta fiche de paie

Pour convertir ton salaire actuel en revenu freelance, commence par regarder ta fiche de paie et identifie ces éléments :

Ton salaire net après impôt. Il correspond à ce qui est versé sur ton compte bancaire à la fin du mois. C'est avec ça que tu paies tes factures et que tu te fais plaisir.
Ton salaire net avant impôt. Il y a encore pas si longtemps c'est cette somme que tu touchais mais il fallait en reverser une partie en impôts sur le revenu. C'est maintenant ton employeur qui s'en occupe, comme ça tu n'as plus rien à payer sur ce qui arrive dans tes poches.
Ton salaire brut. Comme tu le sais probablement, une partie de ton salaire est dédié au financement de contributions et cotisations. C'est ce qui finance la retraite, l'assurance maladie et le chômage, entre autres.
Ton coût total employeur. Il correspond à ton salaire brut plus la part de contributions et cotisations versées par l'employeur.

Pour tout savoir sur les fiches de paie, lis cette édition de la newsletter Snowball : Augmenter son salaire net et apprendre à lire sa fiche de paie.

Le coût total employeur représente ce que ton employeur est prêt à payer pour toi tous les mois. C'est donc une bonne base et ce qu'on va utiliser pour la suite du calcul.

Pour la suite de ce guide, imaginons que tu es dans la moyenne des développeurs fullstack JavaScript avec 5 ans d'expérience et que tu as un salaire brut annuel de 60 000€ avec un coût total employeur annuel de 84 943€ pour un salaire mensuel net après impôt de 3 384€.

Étape 2 : soustrait les congés payés et jours fériés

À priori d'après la convention Syntec tu as droit à 25 jours de congés payés par an (voir un peu plus selon ton ancienneté). Les congés payés n'existent pas en freelance, si tu prends des vacances il te restera moins de temps pour atteindre ton chiffre d'affaire.

Les jours fériés aussi sont rémunérés en salarié, même si tu ne travailles pas (en moyenne 7 jours par an).

Mit bout à bout, un freelance dispose de 32 jours de moins par an. Si une année compte 52 semaines et que tu travailles 5 jours par semaine, il te reste alors 260 - 32 : 228 jours.

Étape 3 : soustrait le temps de prospection et de gestion

En freelance tu vas être amené à travailler avec différents clients qu'il faudra aller chercher. Tu vas aussi devoir passer un peu de temps à gérer ta société. C'est très variable mais partons du principe que tu y dédies 20% de ton temps tous les ans.

Il ne reste plus que 182 jours sur les 228 de départ.

Étape 4 : calcul du tarif journalier

Si tu veux réaliser un chiffre d'affaire annuel de 84 943€ en 182 jours, il faut que tu factures 466€ par jour.

Si ce tarif te permet d'atteindre le même coût employeur qu'en salarié, la différence en terme de rémunération net est importante.

Étape 5 : calcul du revenu net

En freelance tu as besoin de créer une société qui peut avoir différentes formes. Les plus fréquentes sont : micro entreprise, EIRL, SASU ou EURL. Chaque statut a ses avantages et inconvénients qui correspond à des objectifs différents.

Le statut de la société influence grandement ton revenu net alors voyons combien tu pourrais gagner avec un chiffre d'affaire annuel de 84 943€ pour chacun d'entre eux :

Tu l'auras compris, il y a de fortes chances pour que ton revenu net augmente. Mais ce n'est pas tout, les simulations au dessus partent du principe que tu te verses 100% de ton chiffre d'affaire en salaire. En freelance tu as plein d'autres options qui s'offrent à toi.

Tu peux par exemple opter pour un régime d'imposition différent (impôt sur le revenu ou impôt sur les sociétés), choisir de te verser des dividendes ou encore investir via ta société. Tu peux aussi choisir des protections mieux optimisées pour tes besoins, prendre plus ou moins de vacances et faire payer tes frais par ta société (matériel, loyer, abonnement internet / téléphone), entre autres.

À l'inverse, avoir une société engendre des frais. Là aussi on est bien loti mais pense quand même à : comptable, assurance professionnel, mutuelle, prévoyance, compte bancaire professionnel et déplacements (train, repas, logement).

Je t'en dis plus sur les options qui s'offrent à toi et les différentes pistes d'optimisations dans un autre article très bientôt !

Simulateurs en ligne

Comprendre la méthode de calcul est intéressant pour comprendre l'état d'esprit et l'approche à avoir en freelance. Mais pas besoin de refaire les calculs à chaque fois, utilise plutôt un simulateur :

Simulateurs de l'Urssaf
Simulateur de revenus freelancing vs salariat de Shine (lien de parrainage)

Enfin, tu peux également t'inspirer du TJM pratiqué par les autres. Pour ça tu peux faire une recherche sur les plateformes de freelance comme Malt.

Mise à jour le 11/04/2023 : l'Urssaf travaille sur un nouveau simulateur qui permet de comparer les différents statuts au niveau de la rémunération mais aussi de la retraite, santé et autres : Comparateur de statut juridique.

👋 Restons en contact

Je tweet chaque jour ce que ces 10 dernières années m'ont apprises : freelance, clean code, side projects et découvertes.

Pour ne rien rater, suis moi sur Twitter : @gabinaureche.

Garder le Dependabot sous contrôle

Gabin ✨✨ — Sun, 27 Mar 2022 14:52:16 +0000

Le Dependabot est un bot intégré à GitHub qui scanne les dépendances d'un dépôt afin de détecter celles qui ont été signalées comme vulnérables. Lorsque c'est le cas, il crée une alerte visible dans l'onglet "Security / Dependabot alerts" sur GitHub et soumet une pull request avec un correctif qui met à jour la version figurant dans le manifest (par exemple le fichier package-lock.json et / ou package.json).

Le bot est assez malin pour proposer une montée de version qui soit la moins éloignée possible de l'actuelle en respectant les conditions fixées par le manifest. Parfois il n'y arrive pas, pour diverses raisons mais dans ce cas l'alerte est accompagnée d'un message assez clair sur la marche à suivre.

Le Dependabot, ce voisin bruyant

Le problème du Dependabot c'est que par défaut, il peut être assez bruyant. Le fait est que l'arbre de dépendances d'un projet JavaScript moyen est très... riche (les packages JavaScript ont tendance à suivre le principe du "fais une chose mais fais le bien"). Quand on additionne les dépendances du projet avec ses sous dépendances, ses sous-sous dépendances, et etc. on multiplie les chances d'être touché par une vulnérabilité.

En revanche ces vulnérabilités ne sont pas toujours exploitables dans le contexte du projet. Par exemple la dépendance vulnérable n'est peut-être utilisé qu'au moment de build l'application. Ce qui se fait en général dans un environnement isolé où le code vulnérable n'est pas accessible par un attaquant potentiel. Ou alors la vulnérabilité fait partie du code publié mais les conditions de son exploitation ne sont pas réunies. Par exemple elle concerne une partie d'une librairie qui est inutilisée.

Recevoir de nombreuses alertes non pertinentes en continue peut distraire une équipe et lui faire baisser sa garde. Si on s'habitue au bruit et qu'on l'ignore, il devient facile de passer à côté d'une vraie alerte. C'est là le vrai danger du bruit et c'est pour cette raison qu'il faut tout faire pour le réduire et le rendre pertinent.

Configurer le Dependabot pour le rendre pertinent

Mise à jour du 04/05/2023 : GitHub a publié une nouvelle fonctionnalité qui permet de rejeter automatiquement les "faux-positifs". Pas évident de savoir ce qu'ils entendent exactement par là mais ils mentionnent notamment les devDependencies. Commence par l'essayer avant de te résoudre à le configurer manuellement :

Annonce : Dependabot relieves alert fatigue from npm devDependencies

Documentation de la fonctionnalité : Using alert rules to prioritize Dependabot alerts

Suivre les mises à jour : Changelog Dependabot

Un bon moyen de limiter les alertes au code sensible du projet c'est d'indiquer au Dependabot de ne s'intéresser qu'aux dépendances de "production". C'est à dire les dépendances dont le code est exploitable par un attaquant potentiel. Pour un projet JavaScript, il s'agit des dépendances listées dans le champ dependencies du manifest package.json. À l'inverse, le champ devDependencies lui liste les dépendances qui ne sont utilisées que dans un environnement de développement. Pour ça, il suffit de créer le fichier .github/dependabot.yml avec la configuration suivante :

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    allow:
      - dependency-type: "production"

Mais attention, si vous vous arrêtez là vous allez réveiller la partie en sommeil du Dependabot qui va se mettre à vous proposer de mettre à jour toutes vos dépendances. En effet, si le Dependabot est activé par défaut sur les dépôts publics pour les mises à jour de sécurité, l'ajout de ce fichier de configuration activera également les montées de version. Le bot se mettra alors à proposer de mettre à jour les dépendances vers des versions plus récentes. Si votre intention était de réduire le bruit, il y a des chances que ce comportement ne soit pas le bienvenue. Pour désactiver cette partie du Dependabot et affecter les mises à jour de sécurité quand même, il vous faudra la configuration suivante :

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 0
    allow:
      - dependency-type: "production"

L'astuce consiste à mettre une limite de 0 au nombre de pull requests que le Dependabot peut ouvrir. Ce paramètre est l'un de ceux qui n'a pas d'influence sur les mises à jour de sécurité. L'autre paramètre incompatible est target-branch qui permet de spécifier la branche cible pour les pull requests. Si il pourrait être tentant de faire passer la mise à jour par une étape de recette en mergeant sur une branche du type develop, ce n'est pas possible. Et c'est même pire que ça puisque la documentation indique que si ce paramètre est présent, les mises à jour de sécurité ignoreront complètement la configuration :

When you use this option, the settings for this package manager will no longer affect any pull requests raised for security updates.

On peut comprendre la motivation, ça n'a pas de sens de mettre une limite sur le nombre d'alertes. Et quand une vulnérabilité est signalée, c'est déjà trop tard. Elle est dans la nature depuis un certain temps et des attaquants l'exploitent peut-être déjà. Il faut donc proposer un correctif le plus vite possible en production. Mais c'est à garder à l'esprit si vous souhaitez configurer les deux aspects du Dependabot.

Enfin, si cette approche est un bon moyen de réduire les chances de passer à côté d'un vrai risque, il ne faut pas s'arrêter là. Ce n'est pas parce que le code vulnérable n'est utilisé qu'en développement que ce n'est pas un risque. Si il s'exécute sur la machine d'un développeur, il pourrait lui voler sa clé ssh, lire les variables d'environnement, ou encore envoyer des fichiers. Des attaques qui peuvent finir par avoir un impact sur le projet ou l'équipe.

Au delà du Dependabot

Il ne faut donc pas tomber dans le piège de tout ignorer et rejeter. La présence de bruit dans les processus d'une équipe peut être le symptôme d'un problème plus grand. Peut-être que l'équipe manque de temps pour les tâches de maintenance parce qu'elles ne font pas partie intégrante de leur routine. Dans ce cas il serait intéressant de les considérer comme les autres tâches, en les ajoutant au sprint.

Enfin, il existe des alternatives ou compléments au Dependabot comme Snyk ou Socket. Ces services proposent souvent plus d'options de configuration et des interfaces qui donnent un plus grand contrôle. C'est un bon moyen de se simplifier la vie tout en prenant le sujet au sérieux.

👋 Restons en contact

Je tweet chaque jour plein de retours d'expérience comme celui-ci qui te feront gagner du temps : @gabinaureche.

Un side project n'a pas besoin d'être sérieux

Gabin ✨✨ — Thu, 10 Mar 2022 08:15:53 +0000

Depuis longtemps maintenant, je passe une partie de mon temps libre à sauter de side project en side project. Il s'agit pour la plupart d'idées anecdotiques mais j'y met parfois un peu plus d'énergie. Ceci dit, je n'ai jamais eu l'intention d'en gagner de l'argent. Je trouve qu'on entend beaucoup trop parler des side projects qui ont la vocation de devenir un business et pas assez de tous les autres. Ça a pour conséquence de faire circuler l'idée qu'un side project doit forcément être sérieux et qu'il n'a pas de raison d'être si il ne connaît pas le succès. J'ai souvent eu l'occasion d'en discuter avec des ami.e.s, collègues, autres connaissances et pour celles et ceux qui aimeraient avoir un side project mais n'en ont pas, j'ai eu deux catégories d'explication :

Je n'ai pas d'idée.
J'ai une idée, mais je ne suis pas sûr.e que ça marcherait.

C'est dommage d'avoir envie de faire quelque chose mais d'être bloqué.e par ça. Et en vérité dans les deux cas il y a un même problème de jugement de ce qu'est une idée.

Je n'ai pas d'idée

Des idées on en a toutes et tous mais pour s'en rendre compte il faut déjà faire sauter quelques verrous : une idée ça n'a pas besoin d'être révolutionnaire ou utile. Ça peut être quelque chose de déjà vu et complètement inutile. Une idée, ça peut être nulle. Mais même avec une idée nulle, on peut faire plein de choses. Essayer de faire quelque chose de bien avec une idée nulle ça peut amener à explorer des solutions intéressantes. Histoire que ça soit un peu plus concret, laissez moi vous présenter une de mes idées les plus nulles.

Je bossais sur un projet où il fallait éditer des fichiers qui étaient copiés à plusieurs endroits. Je me suis dit, et si on pouvait lancer une interface qui affiche les différences entre les fichiers avec un bouton pour choisir la bonne version et copier partout ? Ça a donné zhouzi/sync-copies. On a dû s'en servir quelques fois avant que ça passe à l'abandon et finisse dans l'oubli. D'après l'historique git j'ai bossé dessus pendant une semaine à raison de quelques heures par ci par là. Ça fait beaucoup pour quelque chose qui a servit à rien.

Mais je n'ai aucun regret, pour plusieurs raisons. La première c'est qu'en me lançant sur ce projet j'avais conscience que c'était de l'over engineering et que personne ne se donnerait la peine de s'en servir. Si je me suis lancé quand même c'est parce que j'y voyais des challenges intéressants à relever. Par exemple ça m'a permit de voir comment ouvrir une interface utilisateur sympa via une ligne de commande. J'ai aussi pu tester des outils de diffing de fichiers avec affichage, et d'autres technos pas du tout adaptées au projet.

Ce qui m'amène au point suivant...

J'ai une idée, mais je ne suis pas sûr.e que ça marcherait

Par "une idée qui marche" est sous-entendu qui connaît le succès. Parce que beaucoup de monde s'y intéresse et/ou parce que ça génère de l'argent. C'est une motivation tout à fait valable. Vous pouvez avoir envie de vous lancer dans un truc en cherchant le succès. Mais il y a plein d'autres raisons d'avoir un side project.

Un side project, une idée, ça peut être un prétexte pour apprendre, essayer de nouvelles choses ou faire des expérimentations. La seule chose, c'est qu'il faut en être conscient dès le début. C'est important de savoir pourquoi vous vous lancez sur un projet parce que c'est ce qui définit comment vous allez l'approcher.

Par exemple si votre ambition c'est de bosser sur un side project qui va marcher, un gros effort de marketing sera nécessaire. Il faut que la proposition soit alléchante, et il faut en parler.

Par contre si vous le faites dans l'objectif d'apprendre et de vous amuser, pas besoin de marketing puisque vous n'avez qu'une seule personne à satisfaire : vous. Et c'est jamais du temps perdu, c'est toujours une expérience qui a de la valeur.

Morale de l'histoire : faites des trucs nuls !

Si vous avez envie de bosser sur un side project, regardez dans votre quotidien et vous trouverez plein de prétextes à essayer des choses. Ne cherchez pas l'idée du siècle, ça ne paiera peut-être pas en argent mais en expérience.

👋 Restons en contact

Je partage mes side projects et autres idées honteuses sur Twitter : @gabinaureche.

Suivre les tendances sans s'arracher les cheveux

Gabin ✨✨ — Sun, 20 Feb 2022 23:39:47 +0000

Le monde de la tech évolue à une telle vitesse que suivre les tendances peut être usant. Le fait est que la veille est souvent présentée comme un effort proactif. Il faut suivre les bonnes personnes, les bons blogs et les consulter régulièrement. Avec un gestionnaire de flux RSS, vous pouvez vous transformer en trader qui tente de tirer quelque chose de flux de données interminables.

C'est faux. Au fil des années j'ai tenté plein d'approches pour rester dans le coup et j'ai fini par trouver quelque chose qui marche, avec peu d'efforts. Mais avant de parler méthodologie, une prise de conscience est nécessaire.

Face à un travail sans fin, il faut choisir ses combats

Tout suivre, c'est impossible. On parle d'un secteur qui est extrêmement vaste et riche. Par exemple si votre kiff c'est le développement front-end, c'est bien de savoir que Kubernetes existe mais vous avez déjà une liste interminable de sujets à éplucher sur ce qui vous branche.

Et même en recentrant sur le développement front-end, entre celui qui aime faire de belles pages animées et celui qui préfère les applications métiers, les technos sont très différentes. Le premier pourrait chercher à devenir un expert de Framer Motion quand le second s'intéressera à du serverless avec Firebase.

On pourrait continuer à recentrer et se rendre compte que le développeur qui veut faire de belles pages à animer, il a un paquet de choix à faire. Au final, les sujets qu'on maîtrise vraiment ne sont pas nombreux et sont le résultat de ce qui nous intéresse vraiment. De ce pour quoi on souhaite se vendre.

Il est donc important d'accepter qu'il est impossible de tout maîtriser. Attention, l'idée n'est pas de mettre les œillères et faire abstraction de tout ce qui est périphérique à vos centres d'intérêts. C'est plutôt que suivre les tendances, faire de la veille, c'est surtout une histoire de culture.

Si vous êtes développeur front-end avec une spécialité sur les belles pages animées, c'est bien de savoir que Kubernetes existe, d'avoir une vague idée de ce que ça fait et de comment ça marche. Et ça peut s'arrêter là.

Mais alors comment faire pour entendre parler de Kubernetes ?

La veille sans effort, ça passe par les newsletters

Faire de la veille ça peut être usant pour trois raisons :

Il faut aller chercher les informations, sur Twitter, des blogs ou autres.
Parmi ces informations, il faut filtrer ce qui a de l'intérêt : parce que ça a de la traction ou que c'est innovant par exemple.
Enfin, il faut creuser ces informations et approfondir.

Tout ça c'est beaucoup de boulot. Un boulot qui est fait par des gens supers dans des newsletters. Parce que c'est exactement ça une newsletter : une liste de ressources filtrées et bien choisies. Et la beauté du truc c'est que ça vient à vous, directement dans votre boîte email.

Gardez quand même à l'esprit qu'une newsletter est une liste limitée de liens sélectionnés par un être humain. Donc pour éviter les biais et avoir une grande et large couverture, le mieux est d'être abonné à plusieurs d'entre elles.

Les newsletters que je recommande

Voici donc une liste de newsletters auxquelles je suis abonné et que je recommande :

React Hebdo - Français, maintenu par Sébastien Lorber. Pour chaque lien il propose son analyse et / ou un résumé. Top pour se faire une idée sans forcément tout lire en détail.
Bytes - Intéressant et toujours très drôle.
Sidebar - Très orienté design.
Web Design Weekly - Web Design.
JavaScript Weekly - JavaScript dans son ensemble, donc top pour ne pas s'enfermer sur une techno.
Frontend Focus - Pour les amoureux du front-end.
React Status - React.
ProductHunt Daily - Un bon moyen de connaître les tendances sur ProductHunt qui est devenu un passage un peu obligatoire pour tout produit.
The Chatty Mammoth - Rien à voir avec la tech ou le web. Il s'agit d'une newsletter payante qui propose 3 articles très variés tous les jours avec un résumé pour chacun d'entre eux. C'est chouette pour s'ouvrir l'esprit et les résumés sont bien faits. Je vous ai mis un lien de parrainage.

Voilà qui devrait donner du grain à moudre. À noter que j'ai testé beaucoup d'autres newsletters, cette liste contient ce qui a tenu dans la durée. Je me suis désabonné des autres.

Apprendre à lire en diagonale

En s'abonnant à différentes newsletter, on s'économise la recherche et le filtrage. Ceci dit, il en reste quand même beaucoup d'informations quand une newsletter contient quarante liens. Alors pour réussir à en venir à bout, il faut apprendre à lire en diagonale. L'idée est tout simplement de dérouler un email en lisant les titres. De cette façon vous vous ferez une culture des sujets du moment. Et lorsqu'un article attire votre attention, ouvrez le. Là aussi vous avez deux possibilités. Soit l'article vous intéresse vraiment et / ou il est assez pointilleux. Dans ce cas une lecture attentive est nécessaire. Autrement, on peut se faire une bonne idée d'un article juste en lisant l'introduction, les titres et les premières phrases de chaque partie.

Encore une fois, j'insiste, l'idée c'est de vous faire une culture des tendances et de vous intéresser de plus près aux sujets qui vous tiennent à cœur.

Et puis en étant inscrit à plusieurs newsletters, il arrive assez régulièrement qu'un article soit partagé dans plusieurs d'entre elles. C'est un bon moyen de détecter les trucs dont tout le monde parle en ce moment. Si ce n'est pas en même temps, ça peut arriver à plusieurs semaines d'intervalles. Par exemple vous pourriez voir un sujet une première fois, puis sous une autre forme quelques semaines plus tard. Là aussi c'est un signe qu'il s'agit de quelque chose qui a de la traction.

Ca n'a donc rien de négatif. Lire en diagonale c'est vous faire une culture, vous laisser du temps pour les sujets qui vous intéressent et ça vous permet de détecter les tendances.

Pour compléter, passez par vos médias favoris

Si il vous reste un peu de temps et que vous souhaitez l'utiliser pour de la veille, faites vous plaisir. Ne vous forcez pas à passer des heures sur Twitter si c'est une corvée. Par exemple je passe beaucoup de temps sur Reddit, pour les memes bien sûr mais il y a aussi beaucoup de contenu très intéressant qui arrive souvent avant les autres médias. Mais je consulte aussi mon flux GitHub, où je suis des développeurs dont j'apprécie le boulot. Mais il y a aussi Hacker News, Product Hunt, Indie Hackers, etc.

👋 Restons en contact

Rendez-vous sur Twitter pour encore plus de conseils de flemmard (mais pas que) : @gabinaureche.

Partager l'état d'une application sans base de donnée

Gabin ✨✨ — Mon, 14 Feb 2022 08:49:21 +0000

La plupart de mes projets personnels sont des applications web sans serveur derrière. La principale raison c'est qu'en terme d'hébergement il existe plein d'offres gratuites sans restrictions pour du "statique". À l'inverse héberger un serveur web c'est souvent payant ou limité, avec par exemple une mise en veille après un certain délai d'inactivité. C'est pas la mer à boire pour de petits projets mais si je peux éviter, j'aime autant.

S'imposer de ne pas avoir de serveur lorsqu'on développe une application web, ça rajoute un challenge qui demande d'être créatif. Par exemple quand on aurait bien besoin d'une base de donnée. On peut y trouver différentes solutions selon le besoin. Si l'objectif est de conserver des données saisies par l'utilisateur courant, on peut passer par du stockage navigateur. Ça se complique si on souhaite que l'utilisateur puisse partager ces données, c'est à ce besoin que cet article apporte des solutions.

Exemple d'état à partager

Imaginons que vous créez un jeu de quizz qui génère un nouveau questionnaire avec différents paramètres à chaque fois que l'utilisateur lance une partie. Imaginons maintenant que vous souhaitez que l'utilisateur puisse partager ce challenge unique avec d'autres personnes, en partageant une URL.

Pour l'exemple, voilà à quoi pourrait ressembler un questionnaire :

const gameState =
{
  difficulty: {
    id: "normal",
    modifiers: {
      timePerQuestion: 5000
    }
  },
  questions: [
    {
      id: 1,
      title: "Quelle est la couleur du cheval blanc d'Henri IV ?",
      answers: [
        { title: "Bleu", isCorrect: false },
        { title: "Blanc", isCorrect: true },
        { title: "Rouge", isCorrect: false }
      ]
    },
    // Ici on peut imaginer qu'il y ait encore d'autres questions.
  ]
}

La solution simple mais limitée

Si on veut permettre à l'utilisateur de partager sa partie, le plus simple serait de le passer en paramètre d'URL :

const gameState = /* le questionnaire présenté un peu plus haut */;

const shareableUrl = `https://mon-questionnaire.com/?gameState=${
  encodeURIComponent(
    JSON.stringify(gameState)
  )
}`;

Lorsque cette URL est partagée et qu'on la rencontre, pour restituer le questionnaire il suffirait alors de l'extraire :

const searchParams = new URLSearchParams(window.location.search);
const gameState = JSON.parse(searchParams.get("gameState"));

C'est simple et potentiellement suffisant mais cette approche a plusieurs limites. La première c'est que les données sont clairement visibles, il n'est pas trop compliqué de trouver les bonnes réponses aux questions. La deuxième c'est qu'on peut se retrouver avec des URLs très longues selon le nombre de questions. Et enfin les données peuvent être éditées et corrompues. J'ajouterai aussi que ça ne fait pas une très jolie URL mais ça c'est mon fétiche.

Dans l'idéal, il faut donc qu'on masque ce qui est partagé, qu'on rende la longueur de la chaîne aussi courte que possible et enfin qu'on s'assure que ce qu'on récupère est valide.

La solution plus complète

Pour obfusquer les données on peut les chiffrer de façon à ce qu'elle ne soit pas lisible dans l'URL mais déchiffrable par notre application à la réception. Ça fait la première partie du boulot mais ça complique un peu la deuxième, qui consiste à raccourir au maximum la taille de ce qu'on met dans l'URL.

Plutôt que chiffrer les données, on peut les compresser. Ça aura pour résultat de les obfusquer tout en raccourcissant la chaîne :

import lzString from "lz-string";

const gameState = /* le questionnaire présenté un peu plus haut */;

const shareableUrl = `https://mon-questionnaire.com/?gameState=${
  lzString.compressToEncodedURIComponent(
    JSON.stringify(gameState)
  )
}`;

Cet exemple utilise la librairie lz-string qui permet de compresser une chaîne de caractère dans un format donné, ici en quelque chose de compatible pour une URL. Ça produit quelque chose du type NoIgpghgzgniA0wBMAGJAWAbC+BGArErigOzyq6b5mpIDMK65aSAnABx6F3HNL1NcdfriaoGrJHx6sAurKA, c'est toujours assez long mais plus acceptable.

Ceci étant dit, on peut aller plus loin dans la compression. Jusqu'à maintenant on a compressé la chaîne de caractère résultante de la sérialisation en JSON du questionnaire. Mais on peut également compresser notre questionnaire en lui même. Par exemple le questionnaire donné en exemple plus haut pourrait être transformé comme suit :

const compressedGameState =
[
  // difficulty.id :
  "normal",

  // questions :
  [
    [
      // id :
      1,
      // On part du principe que les réponses à une question
      // sont tirées au hasard. Elles ne sont donc pas statiques
      // mais propres à ce questionnaire.
      // answers :
      [
        [
          // title :
          "Bleu",
          // isCorrect :
          false
        ],
        [
          // title :
          "Blanc",
          // isCorrect :
          true
        ],
        [
          // title :
          "Rouge",
          // isCorrect :
          false
        ]
      ]
    ]
  ]
]

Pour résumer : on supprime les clés et tout ce qui est statique, qu'on peut retrouver dans notre code. Voilà à quoi pourrait ressembler le code qui permet de passer de l'état non compressé à l'état compressé :

function compressGameState(gameState: GameState): CompressedGameState {
  return [
    gameState.difficulty.id,
    gameState.questions.map(question => (
      [
        question.id,
        question.answers.map(answer => (
          [answer.title, answer.isCorrect]
        ))
      ]
    ))
  ];
}

Et pour décompresser l'état :

import { DIFFICULTIES, QUESTIONS } from "./constants";

function decompressGameState(compressedGameState: CompressedGameState): GameState {
  const [difficultyId, questions] = compressedGameState;

  return {
    difficulty: DIFFICULTIES[difficultyId],
    questions: questions.map(([questionId, answers]) => ({
      id: questionId,
      title: QUESTIONS[questionId],
      answers: answers.map(([title, isCorrect]) => ({
        title,
        isCorrect
      }))
    }))
  };
}

Combiné avec la compression de chaîne, ça donne :

import lzString from "lz-string";

const gameState = /* le questionnaire présenté un peu plus haut */;

const shareableUrl = `https://mon-questionnaire.com/?gameState=${
  lzString.compressToEncodedURIComponent(
    JSON.stringify(
      compressGameState(gameState)
    )
  )
}`;

La dernière chose qui nous manque maintenant c'est de s'assurer qu'on récupère de l'URL quelque chose de valide en se protégeant d'une éventuelle malformation. Il s'agit tout simplement de la validation d'un objet, il existe des librairies bien faites si le cas d'usage est complexe mais sinon ça pourrait donner :

function deserializeGameState(compressedString: string): GameState {
  try {
    return (
      decompressGameState(
        JSON.parse(
          lzString.decompressFromEncodedURIComponent(
            compressedString
          )
        )
      )
    );
  } catch(err) {
    throw new Error("Questionnaire corrompu");
  }
}

Cet exemple illustre la technique du paresseux mais en cas de besoin d'une gestion d'erreur plus fine, il est tout à fait possible de valider les éléments un par un.

Exemple réel et complet

J'ai eu l'occasion de mettre en oeuvre cette approche sur Name the Gwent Card :

zhouzi / name-the-gwent-card

In this mini-game, your goal is to name a random Gwent card from its illustration.

name-the-gwent-card

In this mini game, your goal is to name a random Gwent card from its illustration.

Play

This is an unofficial fan work under the Gwent Fan Content Guidelines. Not approved/endorsed by CD PROJEKT RED.

Credits

This project was inspired by one of Faberstein's mini game he does with his viewers.
Some assets are taken from Gwent's official website, Trendy Gwentleman, and Gwent.one.
The fire sparks particles are taken from codepen.io/coral84/pen/wRZLBe, it uses particles.js.
The cards list comes from Team Leviathan's meta report.

Installation

Note that you do not need to install this application on your machine if you want to use it. Installation is only required if you want to run a development version (e.g to contribute).

Install Node.js.
Clone this repository.
Run npm install in the repository's directory.
Run npm start to start the application.

This project was…

View on GitHub

Toute la logique de compression / décompression et de validation se trouve dans src/app/GameState.ts. Pour voir un exemple, cliquez simplement sur "Play" ou "Jouer" sur la page d'accueil du jeu et observez l'URL.

TLPL

Trop long pas lu, un résumé de l'article en quelques points :

Compresser l'état en supprimant tout ce qui est statique : clés, constantes. Par exemple { answer: "Réponse", isCorrect: true } devient ["Réponse", true].
Convertir l'état compressé en chaîne de caractères JSON puis la compresser, par exemple avec lz-string.
Passer le résultat en paramètre d'URL.
Mettre en place une logique de sérialisation et désérialisation de cette URL vers un état valide.

👋 Restons en contact

Suis moi sur Twitter pour des conseils et astuces tous les jours : @gabinaureche.

Des technos prometteuses #1

Gabin ✨✨ — Tue, 08 Feb 2022 07:09:25 +0000

Parmi toutes les technologies qui naissent chaque jour, parfois j'en identifie quelques unes qui pourraient remplacer ou complémenter les outils que j'utilise au quotidien. Quand c'est le cas je les mets de côté pour les suivre, me documenter à leur sujet et enfin les essayer. Dans cette article je vous partage une sélection de celles que je suis depuis quelques temps et que je testerai dans mes prochains projets. Il ne s'agit pas nécessairement de technologies très récentes mais plutôt du bon moment pour s'y intéresser.

Supabase

Supabase est une alternative open source à Firebase. C'est à dire qu'il s'agit d'un service qui propose authentification, base de donnée, hébergement, stockage de fichiers et fonctions serverless. Côté client il propose une librairie pour se brancher sur la base de donnée sans avoir un serveur intermédiaire.

Ce que je trouve génial dans ce type de service c'est qu'il fournit tout ce qui est commun à presque tous les projets. En s'économisant l'implémentation de briques génériques, on peut se concentrer sur les fonctionnalités uniques à notre produit. Celles qui créent vraiment de la valeur.

Là où il faut être prudent c'est que ça crée une dépendance forte à plusieurs niveaux avec ce service, qui peut devenir dur à quitter. En l'occurence le risque est minimisé par le fait qu'il s'agisse d'un projet open source qu'il est possible d'héberger soit même. Mais quand même, ce n'est pas adapté à tous les projets.

GraphCDN

GraphCDN est un CDN qui répond aux problématiques spécifiques des APIs GraphQL. Le challenge principal tient dans le fait qu'une API GraphQL n'est servit que sur une seule URL. C'est le corps de la requête qui détermine ce qui est demandé et ce qui est attendu en retour. Pour qu'un CDN puisse faire de la mise en cache, il faut donc qu'il soit capable de comprendre ces requêtes.

C'est ce que propose GraphCDN. Dans l'idée ça veut dire qu'avec un cache bien fait, certaines requêtes de l'utilisateur n'arrivent jamais jusqu'au serveur. Ça permet d'avoir des requêtes plus rapides et de soulager la charge. Sur le papier l'idée est géniale, je suis quand même curieux de vérifier que ça ne devienne pas rapidement un cauchemar de configuration et de débogage.

Fathom

Fathom est un service d'analytique pour le web. Pour rappel, ce type de service permet de savoir qualifier les visiteurs d'une page web pour détecter des usages et des comportements. Ces informations permettent ensuite de prendre des actions pour améliorer certains aspects d'un produit. Le géant historique du secteur est bien sûr Google Analytics.

Là où Fathom semble se différencier c'est d'abord parce qu'il est respectueux de la vie privée des utilisateurs. Ensuite le service semble proposer des analyses dont il est plus facile à tirer des actions. Là où Google Analytics est une vraie usine à gaz (parce que très puissant).

Planetscale

Planetscale est une plateforme de base de donnée dans le cloud. Le service offre donc tout ce qui est nécessaire au bon fonctionnement d'une base de donnée comme des sauvegardes régulières et une mise à l'échelle facilité.

N'étant moi même pas très ops, j'apprécie particulièrement ce genre de service qui permet de déléguer cette partie. Le coeur même de l'application étant de fournir une base de donnée, on peut être tranquille sur le fait que les bonnes pratiques soient suivis.

Mantine

Mantine est une librairie de composants React comme il en existe plein. Si je m'y intéresse à celle-ci maintenant c'est parce que j'en entends parler de plus en plus et en bien.

Et effectivement, Mantine propose de nombreux composants mais également des hooks. Ce qui veut dire que d'un côté on a plein de choses toutes faites et prêtes à l'emploi et de l'autre on a aussi la possibilité de construire soit même du plus spécifique avec les hooks. En revanche ce qui m'embête un peu avec ce type de librairie c'est la personnalisation. En l'occurence Mantine le propose via la modification du thème. Bien souvent ça reste limité, surtout sur des personnalisations structurelles.

Radix UI

Radix UI est également une librairie de composants React, mais sans style cette fois-ci. De base les composants ont une apparence très basique, bien souvent celle du navigateur. Mais ils fonctionnent quand même en respectant les règles d'accessibilité.

Ce type de librairie est donc hautement personnalisable. Ce qui en fait un bon outil pour les équipes avec un designer. L'idée là encore c'est d'éviter aux développeurs d'avoir à re-développer des composants génériques en se ratant sur la gestion de l'accessibilité.

👋 Restons en contact

Je partage plein d'outils sur Twitter où j'annonce également les nouveaux numéros de cette série : @gabinaureche.

Faut-il bloguer en anglais ou en français ?

Gabin ✨✨ — Sun, 30 Jan 2022 15:21:56 +0000

Tous les jours on fait notre veille en anglais, on lit de la documentation en anglais, on communique en anglais, on utilise des services en anglais. C'est vrai pour nous français mais c'est vrai aussi pour les autres. Et c'est plutôt cool, c'est ce qui nous permet de lire du contenu écrit par des allemands, des indiens ou tout autre nationalité sans avoir à parler la langue.

L'un dans l'autre, j'ai longtemps conclu que l'anglais était un choix évident pour bloguer et partager du contenu. Jusqu'à ce qu'un jour, parce que je voulais écrire un article un poil plus intime et destiné à un public pas à l'aise avec l'anglais, j'ai fait l'expérience d'écrire en français.

Maman, Papa, je suis développeur front-end et voilà ce que ça veut dire

C'est rapidement devenu mon article avec les meilleurs statistiques sur Medium. Mais j'ai également reçu de nombreux retours positifs en dehors de la plateforme. Cette expérience m'a amené à réaliser que si j'avais bien cerné les inconvénients du français, j'étais passé à côté de ses avantages.

Les avantages de l'anglais

Déjà il y a l'évident : écrire en anglais c'est s'adresser à une très large population. On a donc vite fait de croire que c'est plus facile d'être lu, après tout il y a plus de potentiels lecteurs. Sauf que ce qu'on oublie c'est qu'il y a aussi beaucoup plus de créateurs. C'est un rapport qui a tendance à s'équilibrer.

Un autre avantage de l'anglais c'est que c'est la langue utilisé par une grande partie de nos sources de veille. Quand on écrit en anglais, on s'offre l'opportunité d'apparaître dans l'une d'entre elles. En revanche aucune chance d'être listé dans Sidebar.io, JavaScript Weekly, ou bien encore Frontend Focus en écrivant en français. C'est vrai pour les newsletters et blogs mais c'est vrai aussi pour les plateformes qu'on utilise pour bloguer. Bien souvent elles ont une newsletter dans laquelle elles partagent des articles sélectionnés par la communauté. C'est pas si compliqué d'être sélectionné en choisissant bien ses tags. Mais là encore, le contenu doit être anglais parce que ces plateformes n'ont pas de segmentation forte par langue.

Les avantages du français

Si on décrit le public anglais comme un public de masse, le français serait plutôt une niche. Et les niches, ça a de nombreux avantages ! Parce que le contenu en français est plus rare, il est d'autant plus apprécié. C'est ce que j'ai pu observer avec mon expérience. La première fois que j'ai écrit en français je me suis rendu compte que j'ai mis des mots sur un sentiment commun, qu'on pouvait partager plus facilement. Il y a un vrai sentiment de communauté en français, une volonté de s'entraider pour faire briller les initiatives.

Et parce que les plateformes et newsletters sont plus rares, celles qui existent ont une vraie puissance de partage.

Enfin, j'aimerai qu'on détruise cette idée que ce qu'il y a de meilleur se fait en anglais. Quand on sort de l'école, on a souvent envie d'aller travailler pour Google, Amazon ou Facebook. La réalité c'est que bosser pour ces boîtes c'est tout sauf un rêve, là où on est entouré en France de plein de très beaux projets et de personnes brillantes.

👋 Restons en contact

Je tweet en français tous les jours sur des sujets tech et retours d'expérience de ce que ces 10 dernières années m'ont apprises : @gabinaureche.