En React, tout le code s’exécute traditionnellement du côté client (navigateur). Mais avec les Serveur Components (RSC de son p’tit nom doux), une partie du composant peut être exécuté du côté du serveur, ce qui permet d’envoyer au client du HTML pré-rendu avec données. L’avantage dans tout ça, c’est que le client n’a pas besoin ni de télécharger ni d’exécuter le code JavaScript de ces composants.

Ok mais alors, à quoi cela sert ?

Les RSC apportent plusieurs avantages : 

• Il y a moins de JavaScript à exécuter côté client. La page sera plus légère, donc plus rapide à afficher
• On peut faire un accès direct à la base de données sans passer par une API Rest par exemple.
  Pour être plus précis, sans les RSC, j’aurais besoin d’une API pour accéder à ma database du côté Front. Le back va alors récupérer les datas du côté de la database et les renvoyer au front qui les affichera.
  Avec les RSC, le code étant exécuté du côté serveur, l’accès à la database se fait en direct. Plus besoin d’une API pour l’interroger ! Et donc pas de fetch côté front et gain de performance et plus simple. Attention cependant, les RSC ne remplacent pas totalement les API. On en aura souvent besoin. Le but est juste de dire que l’on peut, dans certains cas, simplifier en passant par des RSC.
• Top côté SEO ! Vu que les datas sont rendues côté serveur et arrive toutes cuites au front, lors de la lecture de la page, tout est déjà rendu et donc mieux pour le SEO pour nos amis comme Google et compagnie. Vraiment un gros plus pour la team SEO qui se tirera moins les cheveux ensuite :)
• On peut mettre une architecture hybride en place. En d’autres termes, tu peux dire que ton composant RSC à une partie qui doit s’exécuter côté client (« use client »).

Mais c’est génial, je vais en mettre partout !!

Oui mais non en fait :) Il y a tout de même des points de vigilances à noter :

• Si vous avez besoin d’un composant interactif avec un useState ou un onClick, cela doit rester un Client Component.
• La frontière entre Client et Server Component ne sont pas toujours très simples. Prenons l’exemple d’un panier. On pourrait se dire que ce serait cool d’en faire un RSC. Mais on a besoin de le mettre à jour, ajouter un code promo par exemple. Et là bim ! Pas possible, cela doit rester côté client. Cela oblige à bien découper ses composants.
• Aujourd’hui, c’est vraiment avec NextJS que cela peut être utilisé. Sur React « pur », comme l’indique la documentation (https://fr.react.dev/reference/rsc/server-components), les RSC sont encore « expérimental » et comportent souvent des changements. Libre à vous de l’utiliser mais attention tout de même sur des applications à mettre en prod :)
• Les outils de debug sont encore jeunes et parfois le debug peut rendre confuse la résolution :)
• Les RSC sont performants oui mais attention, vous déplacez la charge de client à serveur. Et c’est pas une bonne chose non plus. Et par conséquent, les perfs ne seront pas forcément mieux si on en abuse.
• Enfin le côté hybride côté avantage est aussi un inconvénient. À trop vouloir être modulaire, le code en devenir illisible en mélangeant server et client components.

Vous prendrez bien un p’tit verre ?

Ha non pardon c’est plutôt d’hydratation de datas dont nous allons parler ici ^^

Kezako l’hydratation ?

L’hydratation, c’est le moment ou votre page se reveille côté client. Quand vous faites du pain, votre levure se réveille avec de l’eau. Bah dans notre cas, l’eau c’est les datas reçues et notre levure, c’est notre page côté client (désolé j’ai fais du pain maison hier…)

En gros, le serveur envoi du HTML tout prêt. Le navigateur (notre client) affiche lui une version un peu endormie, sans interactivité de notre page. Le JavaScript se charge et React commence à hydrater notre page avec nos datas. Après cela, nos boutons etc sont enfin vivant :)

Exemple :

// Code avant hydratation
<button>Cliquez-moi</button>

// Code après hydratation
<button onClick={handleClick}>Cliquez-moi</button>

Magnifique n’est-ce pas ?

Quand sont rendus les Server Components ?

Point important à retenir : les RSC ne sont pas rendus « en temps réel » à chaque visite. Il y a deux moments possibles :

Au moment du build (Static) :

– Pour du contenu qui ne change pas souvent (page « À propos », documentation)

– Next.js génère le HTML une seule fois lors de la compilation

– Super performant car le serveur n’a aucun calcul à faire

// Static - rendu au build
export default async function AboutPage() {
    return <h1>À propos de nous</h1>; // Pas de données dynamiques
}

À chaque requête (Dynamic) :

– Quand vous avez besoin de données fraîches (posts d’un blog, profil utilisateur)

– Le serveur exécute le composant à chaque visite

– Plus lent qu’en static, mais données toujours à jour

// Dynamic - rendu à chaque requête
export default async function UserProfile({ userId }) {
    const user = await getUser(userId); // Requête DB à chaque visite
    return <h1>Profil de {user.name}</h1;
}

Comment je met en place un Server Component ?

Bah en fait, un composant avec NextJS, c’est automatiquement un RSC :) Mais attention, si vous tentez par exemple de mettre un onClick ou un useState dans un composant, vous aurez un message d’erreur qui vous indique qu’il manque « use client ». Ce dernier permet de convertir le composant en Client Component et devrait être écrit tout en haut du fichier.

Exemple de Server Component

Pour faire très simple, voici un exemple de RSC qui affichera la date du côté du serveur :

// app/CurrentDate.js (Server Component par défaut)
export default function CurrentDate() {
    const date = new Date().toLocaleString("fr-FR", {
        dateStyle: "full",
        timeStyle: "short",
    });
    return <p>Date et heure générées côté serveur : {date}</p>
; }

Comme vous pouvez le voir, il n’y a aucun « use client », pas d’interaction côté front que ce soit avec un useState ou un event de type onClick par exemple. Donc nous sommes en présence d’un composant Server Component.

Mais attends, C’est quoi la différence entre du SSR et RSC ?

Beaucoup de développeur mélange le Server Components avec le Server-Side Rendering. Voici les différences :

SSR

• Tout le composant s’exécute côté serveur
• Puis tout le JavaScript est envoyé au client pour l’hydratation (non on parle toujours pas de boire, un peu de sérieux siouplay)
• Enfin le client télécharge tout le code,même les parties statiques

RSC

• Seuls les composants où on a indiqué « use client » sont envoyé au navigateur
• Le reste (Server Components) reste sur le serveur
• Bundle JavaScript du coup plus petit et plus léger.

Conclusion

Comme tout outil, il peut être utile, mais tout dépend de la façon dont vous l’utilisez. Si vous l’utilisez avec intelligence, vous ferez des merveilles. Mais si vos perfs chutent et que vous en abusez, cela se ressentira également. Et on a pour habitude de dire qu’en général, le problème est entre la chaise et l’écran ;) 

Si vous débutez avec les Server Components, le plus simple est de tester avec Next.js (App Router) qui est aujourd’hui la référence.

Pour résumer :

• Les Server Components permettent de réduire le JavaScript côté client et d’accéder directement aux données serveur.
• Ils ne remplacent pas les Client Components, mais les complètent.
• Aujourd’hui, leur usage le plus courant est via Next.js (App Router).
• Bien utilisés, ils offrent un gros gain en performance et en simplicité, mais il faut apprendre à jongler entre serveur et client.

Merci les ami.e.s et à bientôt !

Longue vie et Prospérité

Hello les ami.e.s !
Aujourd’hui je vais vous faire un petit article sur les containers queries. Accrochez votre ceinture :)

Problématique

Il y a peu de temps, j’ai été confronté à une problématique dans mon travail. On m’a demandé de créer un composant Twig. Il fallait qu’il soit adaptable en desktop et mobile. Je me suis dit : ok easyyy ! Un p’tit coup de media queries et le tour est joué :) La vie est belle quoi. Mais là, je vois la ligne en dessous sur le ticket Jira : Ha, et il faut qu’on puisse le mettre aussi dans une sidebar en affichage mobile. Bon, autant vous dire que mes plans étaient devenus quelque peu foireux. J’aurais bien pu passer un paramètre dans mon composant Twig genre mobile ou desktop, mais pour l’avoir déjà fait, c’est pas hyper fifou.

Et c’est là que les containers queries sortent du chapeau !

Pour répondre à ça, j’ai utilisé les containers queries. En fait, j’avais déjà repéré cette technique CSS dans un article sur FrontendMasters (https://frontendmasters.com/blog/container-queries-and-units/) en décembre 2023. Mais je n’avais jamais tenté son utilisation. De mémoire, je crois que ce n’était pas disponible encore sur tous les navigateurs à ce moment-là, mais je ne mettrais pas ma main à couper ^^

Dis, c’est quoi la différence entre les médias queries et les containers queries ?

La réponse est simple : les médias queries vous permettront d’utiliser la résolution de l’écran en point de référence tandis que les containers queries utiliseront le container parent en référence. En gros dans mon cas, je ne peux pas utiliser les médias queries car mon composant devra s’afficher en version mobile alors que j’affiche une version desktop. Mon composant serait totalement pété dans la sidebar !

Comment que ca marche-t’y donc ?

Déjà, je vous mets en garde tout de suite : cet article n’est pas un tutoriel complet sur les containers queries mais seulement (et c’est déjà pas mal hein !) pour vous mettre un pied à l’étrier. Je ne remplacerais pas la documentation MDN. El Famous RTFM :P

Mettons-nous en situation et partons du même principe avec un élément main et un élément aside avec un width totalement arbitraire de 350px.

Voici la tête de mon « composant » :

<div class="main-component">
    <div class="component">
        <img src="https://cataas.com/cat?width=300&height=300" alt="">
        <p>My legend</p>
    </div>
</div>

A noter, instant promo, cataas.com est un super site d’image de chat pour vos placeholders :) C’est gratuit, allez-y !

Je dois d’abord donner un nom et un type de comportement à mon container query :

.main-component {
    container-name: myComponent;
    container-type: inline-size;
}

Je définis le type en inline-size car je veux checker le comportement sur le width (si j’ai bien activé tous mes neurones :P) N’hésitez pas à dire en commentaire si besoin.

Le nom va me permettre de définir un comportement pour ce bloc de code et pas un autre.

Maintenant, je veux dire que mon bloc se comporte comme ceci : 

• l’image doit être en format petit et arrondi
• le nom sur la droite de l’image

Bon c’est simple, en mobile first, on va directement le définir comme ça :

.component {
    display: flex;
    align-items: center;
    gap: 16px;
    img {
        width: 100px;
        height: 100px;
        border-radius: 100%;
    }
}

Maintenant, je veux que, lorsque mon bloc s’affiche dans un espace de plus de 350px (donc plus grand que mon aside) :

• l’image doit faire 300px en width et height
• un border-radius de 16px
• le texte dois s’afficher dessous et centrer sous l’image.

On écrira du coup le code suivant :

@container myComponent (min-width: 351px) {
    .component {
        display: inline-block;
        text-align: center;
        img {
            width: 300px;
            height: 300px;
            border-radius: 16px;
        }
    }
}

@container rappelle l’utilisation du @media. On appelle le nom myComponent défini dans container-name plus haut. Et enfin le reste du code vous comprenez :)

Vous voyez, rien de bien compliqué.

Je vous ai fait un CodePen très rapide pour les besoins de l’article. N’hésitez pas à le checker (et checker mes autres Pen si vous savez pas quoi faire ou si vous êtes curieux ^^ Vous n’imaginez pas tout ce que l’on peut faire avec le CSS :)

See the Pen Introduce to Containers queries by Stephane (@Tef) on CodePen.

Les commentaires sont ouverts si vous avez besoin de vous exprimer, m’envoyer du love ou me rendre riche et célèbre (ouais, là non, je ne pense pas).

Merci les ami.e.s et à bientôt !

Longue vie et Prospérité

Avant toutes choses :

Cela fait un moment que je n’ai pas écrit d’article. J’étais pleins de bonnes résolutions (comme d’hab’ quoi), mais la charge de travail, le Covid (saloperie va) et un changement de taf et de logement avec la construction de ma maison on fait que j’ai un peu délaissé ce blog. L’article que vous allez lire est en brouillon depuis 2 ans !! Autant dire qu’il a eu le temps de bien se reposer ^^ Bref j’ai fais un p’tit coup de ménage et je le poste tout de même :) Bonne lecture !

P.S : Putain ca fait plaisir de vous revoir :P

Salut les amis !

Bon ce n’est pas parce qu’on parle de code ici qu’on ne doit pas connaitre les bases du travail collaboratif avec git. Mon but ne sera pas de vous faire un cours sur git avec création d’un repo car la doc est assez bien foutu pour ça. Mais cet article est plus là pour vous donner les billes pour « pousser » ou « récupérer » vos modifications et ainsi sécuriser votre travail en cas de crash de disque dur ou tout simple pour bosser avec d’autres personnes.

Déjà pourquoi connaitre ces commandes de base Git ?

Il est important de comprendre ce que l’on fait. Vous pourriez très bien utiliser votre IDE et cliquer sur les boutons à disposition. Après tout, tout est là pour ça et pour vous simplifier la tâche. Mais perso, même si j’utilise PHPStorm au quotidien, je préfère encore faire manuellement dans mon terminal mes push, rebase, commit, etc. Et je pense sincèrement qu’il est important de savoir ce qu’il y a derrière une action et pourquoi on l’utilise.

Commençons !

Je pars du principe que vous avez initialisé votre repository (repo pour les intimes) dans votre projet.

A noter : on lance une commande git toujours en mettant git en premier.

Voici donc quelques commandes non exhaustives qui pourront vous servir. Je vais sûrement en oublier, donc ne criez pas au scandale s’il en manque mais le but est juste de donner des premières commandes et de ne pas réécrire la documentation ;) :

• git status : Avec cette commande vous allez voir le statut de tout ce qui est en cours de modifications en local et qui n’a pas été push sur votre repo. (nous verrons plus bas ce que c’est que le terme push). Exemple : 
  
• git add : Alors là, je ne vais pas réexpliquer car j’ai écris un article assez détailler sur le sujet par ici :)
  
  
• git commit : Cela vous permet de valider les modifications et de les réserver dans un coin. Attention à ce stade vous n’avez toujours rien envoyé sur le repo. A noter que vous pouvez ajouter des paramètres et faire un git commit -m « mon message » mais je ne vous conseille pas de faire ceci. Avec un simple commit vous serez plus à l’aise pour saisir un chouette commit bien structuré ;) On y reviendra plus tard.
  Vous pouvez également cumuler plusieurs git commit si besoin. Toutefois, éviter de faire plusieurs git commit juste pour une faute d’orthographe par exemple. Essayez d’être structuré dans vos actions :) Au pire, utiliser un rebase pour merger vos commits.
  
  
• git push : push va permettre de « pousser » (push = pousser vers votre repo) vos modifications sur votre repo. Plus exactement, cela va pousser les modifications sur la branche distance équivalente à la votre en local sur le repo. C’est à ce moment-là que votre git commit va être envoyé.
  A noter qu’à la création d’une branche, le premier push que vous ferez risque de râler un peu :P Sur le premier push au lieu d’un simple git push vous devrez faire git push –set-upstream origin fix/ma-branche2 (ou git push -u origin fix/ma-branche2 pour la version raccourcie). En gros pour schématiser un peu, un push va chercher sa référence sur le « catalogue » distant pour lui envoyer ses modifications. S’il ne le trouve pas, il vous insultera ^^ Donc, le -u va permettre de créer une référence dans le catalogue distant, puis pousser ses modifications
  
  

• git pull : pull va permettre de « récupérer » (pull = tirer vers soit, ramener du repo vers notre local) les dernières modifications qui sont sur votre repo. En général, on utilise cela quand vos collègues ont mergés leurs branches et que vous voulez mettre à jour votre local pour récupérer leur taf.

• git checkout feat/ma-branche : vous permet de basculer sur une autre branche (en l’occurrence, ma-branche dans notre exemple et se situe dans feat)
• git checkout -b fix/ma-branche2 : vous permet de créer une nouvelle branche grâce au paramètre -b et de basculer dessus. Dans notre exemple nous venons de créer une branche ma-branche2 dans fix et nous avons basculé dessus automatiquement.
  
  
• git log : vous permet de voir les logs de tous les push que vous et vos collègues ont fait sur la branche
  
  
• git fetch : vous permet de mettre à jour les infos sur la branche distante sur laquelle vous travaillez. En gros voyez ça comme une mise à jour du catalogue que vous avez en local. Pour schématiser, le fetch va interroger votre repo, récupérer la liste des branches disponibles et leurs états et mettre à jour votre « catalogue » local. Attention fetch ne remplace pas pull. A noter que pull fait les 2 : il fait d’abord un fetch et ensuite il met à jour la branche en local.
  Astuce : Ajoutez le paramètre –all (git fetch –all ou git fetch -a dans sa version raccourcie) pour mettre à jour son « catalogue » local de toutes les branches distantes disponibles.
  
  
• git branch –list : Cela va vous lister toutes les branches que vous avez en locale. Et c’est aussi à ce moment-là que vous ferez un arrêt cardiaque en vous rendant compte du merdier que vous avez accumulé. C’est là qu’une voix dans votre tête ressemblant à celle de votre mère vous dira : « Mais tu vas la ranger ta chambre !!? C’est le bordel ici !! ».
  Ne vous inquiétez pas, j’ai la solution : git branch -d feat/ma-branche. Et parfois, pour une raison que je n’ai pas trouvé, vous ne pourrez pas supprimer une branche. Remplacer -d par -D qui est l’équivalent d’un -d –force.
  Astuces : Vous pouvez très bien supprimer plusieurs branches d’un coup : git branch -d feat/ma-branche fix/ma-branche2.

Petit bonus :

Ecrire (selon moi bien entendu) un bon commit :

Ce que je vais vous présenter ici est, selon moi, une bonne façon d’écrire un commit. Attention cela dépendra aussi de votre entreprise et de ses besoins/méthodes de travail. Donc cela n’engage que moi mais libre à vous de faire votre propre rédaction de commit. Le plus important est que cela soit lisible et que tous vos commits soient homogènes entre collègue.

Une fois le git commit fait, voici une structure propre pour vos commits :

feat(header): champ recherche
Ajout d'un champ de recherche dans mon header

fix(header): champ recherche
Correction de mon champ de recherche dans mon header

Vocabulaire :

• feat = feature = nouveauté
• fix = correction

Voilà vous avez une première base avec des commandes de bases pour faire du git pour vos projets. Je n’ai pas tout aborder, comme le rebase mais vous pourrez trouver plus d’information sur cet article que j’avais écris ici :) 

Bon git !

Longue vie et prospérité !

Salut les amis !

Cela faisait un p’tit moment que je n’avais pas écrit d’article, mais il faut dire que cette période a été un peu compliquée pour tout le monde :) Et j’ai été pas mal occupé également.

Il y a quelques mois, je m’étais forcé à utiliser Git dans le terminal et plus en mode « clic clic » dans mon éditeur de code sans comprendre ce que je fais réellement. Et que ce soit au taf ou pour moi perso. Et je dois dire qu’aujourd’hui c’est devenu naturel. Au point que lorsque je clique sur un bouton pour faire une action Git, j’ai honte et je regarde autour de moi si on m’a vu.

Aujourd’hui je voudrais mettre en lumière 2 façons d’ajouter vos fichiers dans l’index pour commit et vous pourrez ne plus utiliser le sempiternel git add .. Que l’on soit d’accord : ce n’est pas les meilleures façons d’ajouter, mais bien les façons que moi je peux conseiller. Encore une fois, je ne suis pas un pro du git, et il est fort possible qu’il existe une meilleure façon de faire. Donc, n’hésitez pas à me le dire en commentaire :)

Pourquoi je n’aime pas git add . ?

La réponse sera simple et courte : je ne trouve ça pas trop propre et vous ajoutez tous vos fichiers comme un bourrin dans l’index de commit sans vous souciez de ce qui a été modifié. OK c’est plus rapide, mais une erreur est vite arrivée et vous pouvez insérer des erreurs inutiles qui vous feront chier par la suite.

S’il vous plait, plus de git add . !

Comme pour mon article sur le git rebase interactive, je vais fonctionner avec des copies d’écran pour que vous compreniez bien.

Faisons un git status :

Nous pouvons voir un fichier modifié et un fichier non ajouté dans l’index : on dit que le fichier est untracked.

Un peu de vocabulaire

Voyons cela rapidement :

• Untracked : votre fichier est nouveau et n’est pas encore inscrit dans l’index du commit En gros il est là, il attend qu’on veuille bien de lui et n’est existant qu’en local sans interaction avec votre branche locale. Il apparaît en rouge dans le statut.
• Changes not staged : votre fichier est inscrit dans l’index mais a été modifié. Il apparaît en rouge dans le statut
• Changes to be commit : votre fichier a été ajouté à l’index du commit et est prêt à être commit. Il apparaît en vert dans le statut.

1 : Git add -p

La première façon est git add -p. le -p veut dire patch. En gros vous allez parcourir chaque modification dans chaque fichier modifié, voir les modifications et dire si oui ou non vous voulez l’ajouter. Essayons ! Allez hop :

Bon OK la différence est subtile, c’est l’indentation. Mais c’est pour les besoins de l’article ! Ne me jugez pas, je suis pas là pour souffrir OK ??!

Là on a pas mal de choix possible ! Stage de hunk, à traduire par ajouter ce bloc :

• y : cela va parcourir le fichier et afficher chaque différence. Et à chaque différence on vous demandera ce que vous voulez faire.
• n : vous refusez d’ajouter le fichier complet. Il passe au suivant
• q : vous quittez le git add -p (c’était trop dur :P)
• a : vous allez accepter ce bloc et toutes les autres modifications seulement sur ce fichier. 
• d : vous refusez ce bloc de modification et toutes les prochaines modifications et vous passez au fichier suivant. La différence est subtile avec n mais ce dernier refuse le fichier au complet alors que d lui vous pouvez accepter par exemple les 2 premières modifications et refuser les suivantes.
• g : vous pouvez choisir le bloc modifié sur lequel vous voulez aller. C’est pas mal pour parcourir vos modifications.
• / : si vous êtes un fou du regex, cette option est faite pour vous :P
• J : si vous êtes indécis sur ce que vous voulez faire de cette modification, cela permet de mettre ce bloc en undecided et de passer au bloc modifié suivant. 
• j : vous laissez ce bloc en undecided et vous passez au prochain bloc qui a le statut undecided
• e : permet de modifier le bloc en live avec nano ou VI
• ? : affiche l’aide que je viens de me faire chier à vous expliquer ! :P

Point positif :
Cette solution est vraiment pas mal. Vous pouvez interagir avec vos fichiers modifiés inscrits dans l’index pour chaque bloc.

Point négatif :
Je regrette juste que ce soit assez chiant quand on a beaucoup de modification et de fichiers modifiés. Et quid des fichiers en untracked ? On risque de les oublier et on est obligé de faire un git add monfichier pour l’inscrire dans l’index de commit.

2 : Git add -i

La seconde méthode est ma préférée. C’est la façon interactive. Je trouve cette méthode assez claire car elle regroupe plusieurs commandes, dont le patch que nous venons de voir. Allez c’est partie, faisons un p’tit git add -i :

Ce qui est intéressant avec cette méthode, c’est qu’en théorie vous ne pouvez pas louper un fichier untracked car il y a une option pour ça dans la version interactive.

Expliquons les options :

• 1 (ou s) : affiche le statut des fichiers dans l’index de commit. (Important : juste dans l’index de commit !)
• 2 (ou u) : liste les fichiers que vous voulez ajouter dans l’index de commit au cas par cas. Soit vous tapez le chiffre, soit la lettre qui est en gras et couleur pour sélectionner vos fichiers
• 3 (ou r) : liste les fichiers que vous avez ajoutés dans l’index de commit pour faire un retour arrière. Vous sélectionnez le ou les fichiers voulus et cela les renverra à l’état initial au tout début du git add -p (soit unchanged, soit untracked)
• 4 (ou a) : liste les fichiers non inscrit dans l’index de commit pour les ajouter au cas par cas. A vous de sélectionner les fichiers voulus
• 5 (ou p) : liste les fichiers modifié et inscrit dans l’index de commit pour passer en revu les modifications et voir quoi ajouter ou refuser. Vous vous retrouvez avec le patch vu juste ci-dessus grâce à la commande git add -p.
• 6 (ou d) : liste les fichiers ajoutés dans l’index de commit et vous montrent les différences entre vos modifications et le code original.
• 7 (ou q) : vous quittez le git add -i. :)
• 8 (ou h) : affiche l’aide !

Voici un exemple si vous tapez a (add untracked), vous avez le listing des fichiers à ajouter dans l’index de commit. Et même principe, le chiffre ou la lettre en gras pour l’ajouter ! Et vous faites la touche Entrée sans rien saisir pour revenir au menu précédent :

Point positif :
J’aime cette solution. Elle permet de ne rien oublier, de tout contrôler. Bref vous l’aurez compris c’est ma méthode préférée.

Point négatif :
Très honnêtement je n’en ai pas trouvé. :P

Voilà ! Après tout ça, j’espère vous avoir fait abandonner le git add . bien bourrin et être plus consciencieux dans vos ajouts de fichiers sur vos branches :)

Longue vie et prospérité !

J’ai la chance, et je dis bien la chance, de pouvoir faire du télétravail. Certains diront que c’est tout à fait normal dans notre métier. Mais la réalité est tout autre. En France, même si cela commence un peu à venir, pas mal de sociétés ont encore du mal à faire confiance à leurs employés. Pour beaucoup, le télétravail est synonyme de glande devant un bon film avec un p’tit café et un donut pendant que les collègues bossent comme des oufs.

Mais nous allons essayer de décortiquer cela ensemble et voir si t’es fait pour ça et comment bien y arriver.

Je te préviens tout de suite : je ne suis pas un expert du télétravail. Mais je vais te parler de mon expérience personnelle et comment moi, simple mortel, je vois les choses. Pour te donner un ordre d’idée, dans mon ancienne boite, j’ai bossé en télétravail presque 1 an et demi. Au début 1 jour comme ça, puis la société allait mal (rien à voir avec le télétravail hein) et je suis passé à 3 jours puis full télétravail. Maintenant dans l’agence actuelle, je suis à 2 jours fixes par semaine. Et je crois bien que ça fait plus d’un an et demi maintenant. Donc voilà je pense que je peux t’en parler un peu !

Pourquoi faire du télétravail ?

La question parait toute conne, pourtant, il est important de se la poser. Faire du télétravail, juste pour dire qu’on en fait ou pour être libre d’aller acheter son pain au chocolat le matin n’est pas la bonne solution. Tu dois te demander si vraiment cela est nécessaire pour toi. Prenons mon exemple. J’ai 42 ans depuis hier (oui en théorie je vais poster cet article le lundi 14 octobre, contactez-moi en PV pour m’envoyer des cadeaux ou de l’argent ce sera avec plaisir :P). J’ai pas mal bougé dans mon précédent métier, j’étais toujours sur la route. Souvent levé à 5h du matin et rentré à 20h. Aujourd’hui, j’ai 2 enfants qui grandissent bien trop vite. Le matin entre le train et la voiture et le trajet à pied je mets 1h30 minimum. Et ça, c’est juste le matin donc je fais la même chose le soir. Et souvent bien plus à cause de la circulation ou les trains en retard (merci la SNCF, big love for ever)

Le télétravail est vraiment une qualité de vie non négligeable ( en plus de mon rendement, mais je parlerais de cela plus tard). Mais voilà l’agence web dans laquelle je travaille me fait confiance et la confiance n’est pas unilatérale. Et je peux t’assurer que quelqu’un qui triche, ça se voit très vite. Surtout dans les agences web où le travail est souvent en flux tendu. Et je suis très a cheval sur la confiance. Tricher ne t’amènera que des problèmes dans ta vie pro (c’est mon côté papa ça désolé).

Suis-je fait pour le télétravail ?

Là aussi la question est importante. Pose-toi la question de savoir si tu peux rester chez toi sans avoir envie de regarder les infos sur ton équipe de foot favorite toutes les 10 minutes. Je connais quelqu’un qui bosse dans le web qui m’a dit mot pour mot : « Franchement moi je ne pourrais pas faire du télétravail, j’aurais toujours envie de regarder Netflix ». Je trouve ça honnête et clair. Il est important d’être honnête avec soi même. Tu n’y gagneras rien en faisant croire que tu vas y arriver, mais rien ne t’empêche d’essayer (même si tu sais déjà que tu vas dégainer ton compte Netflix au bout d’une heure). Et comme je te l’ai dit plus haut, si tu triches, cela se verra. Et c’est entre toi et ta conscience que ça se joue.

Demande-toi aussi si l’interaction avec tes collègues est importante pour toi ou si tu préfères te couper une jambe plutôt que de parler à des gens. Entre nous l’ami(e), si tu penses à la seconde option, va vite consulter quand même. Si si, vite vas-y, tu te rendras service. Dis toi que le télétravail peut être synonyme d’isolement. Mais ça aussi, nous en parlerons plus tard. Mais pose-toi la question, c’est important.

OK, mais comment y arriver ?

Tu as vu que le télétravail est bien pour toi et que tu penses pouvoir réussir. OK c’est top. Après pour y arriver, moi je vais te donner ma façon de procéder. Ce ne sera peut-être pas la façon la plus optimale et possible même que cela ne soit pas bon pour toi. Mais comme je t’ai dit plus haut, je vais te parler de ma façon de faire. N’hésite pas à commenter, je suis preneur et intéressé, comment tu travailles chez toi si tu fais déjà du télétravail !

Déjà il faut définir ton environnement de travail. Ce que j’avais fait au début, c’était de voir où et comment j’allais m’y prendre. Depuis le début, je suis sur mon ordinateur perso fixe. La configuration de notre appartement est telle que le seul endroit que j’ai pour travailler est le salon. Dans ce cas, le facteur le plus important est de placer tes jours de télétravail quand t’es tranquille sans personne. Dans un peu plus d’un an avec ma femme, on aura fini de faire construire notre maison et j’ai prévu un bureau. D’ici là j’aurais aussi probablement un ordi portable du boulot. Tout sera plus simple. Ma femme pourra être là le jour de mon télétravail, je ne serais pas dérangé et toujours concentré.

Une fois le lieu défini, parlons du matériel. Dans le web, le double écran c’est quand même le tarif minimum. Ça reste mon avis, mais bon, des fois, je me dis qu’un 3ème écran ne serait pas du luxe. Alors un seul écran, ça me ferait un peu chier quand même.

Si comme moi tu bosses sur ton ordinateur fixe perso, soit tu te fais une session personnelle, soit comme moi tu bosses sur un second bureau virtuel. Et si comme moi, tu bosses sur Windows (ne me jetez pas la pierre, si j’étais seul j’aurais remis ma Debian), mets dans Système / multitâche le select appelé « Dans la barre des tâches, afficher les fenêtres ouvertes sur » sur l’option « Le bureau que j’utilise uniquement« . C’est tout bête, mais si tu ouvres une fenêtre sur ton bureau « perso » l’icône n’apparaîtra pas dans la barre des tâches de ton bureau « pro ». Tu pourrais très bien caché ta barre de menu, mais par expérience, on est de grands enfants : Plus tu caches et interdits, plus tu vas être tenté de regarder et toucher !!

Dernière configuration que je te conseille sur ton Windows : clique droit sur ton icône de notifications tout en bas à droite et mets l’assistance de concentration sur Priorité uniquement. Tu peux recevoir des mails, etc., tu n’auras plus de notification. Personnellement, même au bureau j’ai désactivé les notifications.

Voilà avec ça je pense que t’es paré. Après il te reste plus qu’à installer ton environnement. Je te conseille d’être à l’identique avec ton ordi du bureau, que ce soit en termes de logiciels ou d’environnement serveur si tu utilises un serveur local.

Bienfaits et mise en garde

Alors on a parlé un peu des deux, mais il est important de développer tout ça. Les bienfaits ne sont plus à prouver. Tu te lèves plus tard, tu n’as plus le souci et la fatigue du trajet. Tu n’es pas stressé sur le timing pour aller prendre ton train (s’il est là….. houuuu que je suis méchant…). Tu n’es pas guindé dans un costume si tu as l’habitude de t’habiller en pingouin pour aller bosser (désolé pour toi si tu mets un costard pour aller faire bosser). Le midi tu manges dans ton environnement personnel et le soir tu fermes tout et tu peux retrouver ta famille 10 secondes plus tard. Et là franchement ça n’a pas de prix.

Par exemple moi les vendredis je finis à 17h. Je fais mon télétravail et à 17h je coupe. Je suis déjà à la maison. 10 min plus tard, je peux filer avec ma famille faire les courses si besoin et ne pas rentrer trop tard. La semaine ? 18h je coupe et 5 min après je peux aller faire faire les devoirs à mes enfants et plus laisser ma femme seule devant tout ça ou faire la vaisselle ou /et le repas.

Autre bienfait, mais là c’est personnel, je suis bien plus performant quand je suis en télétravail. Mon rendement est meilleur. Un problème de code ou je buterais au bureau, bizarrement je trouve plus vite chez moi. Au bureau, il faut se dire que le moindre mouvement autour de toi attire ton attention. Ce n’est rien comme ça, mais ça suffit pour te déconcentrer. Et plusieurs fois dans la journée ça peut être perturbant.

Il y a aussi ton DT qui tente de te percer le crane avec son Nerf à distance pendant que toi tu voudrais éclater les petites pattes arrières à ton maudit code qui ne veut pas marcher (si tu lis cet article cher DT, je suis un homme mort, je sais). Tu as aussi le/la collègue qui se lève et vient te voir pour te demander un truc. Le/la chef de projet qui a besoin de toi pour un chiffrage (chiffrage qui peut attendre probablement, mais toujours plus simple de t’en parler de vive voix). Mais tu galères pour te remettre dans ton code ensuite.

Mais chez toi, on t’envoie un mail tout simplement. Et toi tu t’organises. Tu te dis que la première demi-heure tu traites tes mails, ensuite tu bosses sur tes projets et vers 11h30 tu regardes et traites de nouveau tes mails. Ou plusieurs fois dans la matinée c’est toi qui vois suivant ta fonction dans la société et l’exigence demandée. Mais je ne jette pas la pierre à ces personnes, car je suis sûr que je fais la même chose avec eux. C’est humain, on a besoin d’interactions avec son entourage pro.

Dernier bienfait : le télétravail c’est quand même une sacrée économie !! Mon plein de voiture me tient presque le mois (je dis presque, faut pas abuser quand même). Et au-delà de l’économie de carburant, tu abîmes moins ta voiture, etc. Bref on n’y pense pas à ça, mais c’est important.

Mais, il y a toujours un, mais, il y a aussi des inconvénients.

Si tu n’as pas de bureau pour toi et que tes enfants et/ou ta femme ont du mal à comprendre que le télétravail c’est comme si tu n’étais pas là, bosser va vite devenir un enfer pour toi. Moi je n’ai pas ce problème, mais honnêtement, si c’était le cas, j’aurais tout de suite arrêté. C’est un coup à ne pas tenir des objectifs et perdre la confiance de ton boss.

Autre souci, et pas des moindres, l’isolement. Si tu es juste à 1 ou 2 jours de télétravail, c’est largement jouable. Mais plus, cela peut vite devenir compliqué. Il y a quelque temps, pour des soucis de santé, la médecine du travail avait demandé que je passe à 3 jours de télétravail. Mais je me suis rendu compte que c’était trop. Alors oui j’ai déjà fait du full télétravail comme je l’ai précisé plus haut. Mais la situation était différente. On était 3 employés, 3 en télétravail. La société allait malheureusement mal et il fallait qu’on bosse de chez nous. Mais l’agence web actuelle est pérenne. Tout le monde bosse bien, les boss s’investissent vraiment, du coup il n’y a pas lieu de faire plus de télétravail que ça pour moi. Et dès que j’ai pu, je suis repassé à 2 jours comme convenu initialement. J’ai vite senti la limite. Je commençais à me rendre compte que je loupais tout. Ça n’a pas duré longtemps, mais j’ai perdu quelques affinités avec quelques personnes. Ne néglige JAMAIS le côté humain. Ça fait cliché de dire ça, mais bosser dans une agence web, c’est aussi une aventure humaine. Tu réussis, tu galères, mais tu le fais en équipe. Si tu t’isoles trop, tu perds tout ça.

Un autre point : le télétravail ce n’est pas la fête à neuneu. T’es peut-être chez toi, mais tu travailles. Donc il faut bien comprendre (et faire comprendre à ton/ta conjoint(e) si il/elle est présent(e)) que c’est comme si tu n’étais pas là. T’es pas là pour faire une lessive, la vaisselle ou pour jouer à la XBox à la moindre pause. Non au bureau tu ne fais pas tout ça. Personnellement je me mets dans cette situation : jour de télétravail, à partir de 8h30 je me comporte comme au bureau jusqu’à 18h. Avant ou après tu fais ce que tu veux. Le midi je mange et je fais ce que je fais au bureau en règle général.

Dernier point important, si t’es assidue dans ton travail au point de faire du zèle, le risque que tu peux avoir c’est d’avoir la sensation de ne jamais t’arrêter de bosser.Si tu fais du zèle au bureau, tu le fais dans un autre lieu que chez toi. Tu sors du bureau et tu as ta coupure. Mais chez toi, tu n’as pas cette coupure. Et c’est encore plus vrai si tu n’as pas actuellement de pièce dédiée chez toi pour le télétravail. Le zèle c’est bien, mais attention : ne va pas trop loin. Il ne faut pas qu’être chez toi devienne une tannée.

Voilà, je pense qu’on a fait le tour. J’ai probablement oublié certains aspects du télétravail. N’hésites pas à me dire en commentaire, je te répondrais avec plaisir. En tout cas, j’espère t’avoir un peu éclairé sur le télétravail en te parlant de mon vécu. Et si tu ne sais pas quoi faire maintenant, je t’invite à lire mon dernier article sur Git rebase, tu vas voir c’est instructif et ça va changer ta vie :)

Longue vie et prospérité