DEV Community: Antoine Caron

Engineering manager : les métriques que je surveille

Antoine Caron — Thu, 15 Oct 2026 17:18:10 +0000

Cet article a été publié initialement sur mon blog.

C'est le quatrième article de ma série sur ce que le rôle d'engineering
manager m'a appris. Comme pour les épisodes précédents, ce qui suit n'est ni
une méthode ni une vérité générale : c'est un retour d'expérience personnel,
structuré autour des citations et des principes que des personnes qui ont
compté dans mon parcours m'ont transmis, et de ce qu'ils m'apportent au
quotidien.

Le premier épisode portait sur le rôle et la posture d'engineering
manager, le deuxième sur le
1:1 et le suivi individuel,
le troisième sur donner des objectifs et de la
vision. Vous pouvez retrouver
tous les articles de la série sur la page du tag
engineering-management.

Ce billet-ci se concentre sur les métriques que je surveille en tant
qu'engineering manager : lesquelles j'utilise vraiment au quotidien, celles
dont je me méfie, et la façon dont je les lis : pas comme des absolus, mais
comme des tendances.

N'hésitez pas à me proposer les métriques que vous suivez avec vos équipes :
je serais curieux de découvrir comment chacun aborde le sujet. Mes réseaux
sont accessibles depuis ce blog.

Pourquoi je surveille des métriques

Avant de parler des chiffres eux-mêmes, une précision sur la posture. Une
métrique, ce n'est pas un tableau de bord qu'on brandit pour justifier une
décision. C'est avant tout un instrument de calibrage : elle m'aide à
comprendre où en est l'équipe, à détecter tôt un problème, et à savoir si mes
choix de découpage ou de priorisation produisent l'effet attendu.

J'avais déjà posé cette idée dans l'article précédent à propos du lead time :
ce n'est pas un outil de flicage, c'est un instrument de calibrage. La même
logique s'applique à toutes les métriques. Dès qu'un chiffre sert à juger une
personne plutôt qu'à comprendre une situation, il devient toxique, et je
reviendrai sur ce point à la fin.

Ce qui ne veut pas dire grand-chose : la vélocité

« La vélocité individuelle ou même la vélocité de l'équipe, ça veut pas
dire grand-chose. » (Florent Dubost,
mon manager pendant plusieurs années)

C'est une phrase que je me répète souvent, parce que la vélocité a tout pour
plaire : elle se calcule facilement, elle se résume en un chiffre, et elle
donne l'impression de mesurer « combien on produit ». Sauf que ça ne mesure
en réalité presque rien.

D'abord, comparer la vélocité de deux équipes n'a aucun sens : chaque équipe
découpe, estime et compte ses points à sa façon. Ensuite, même au sein d'une
même équipe, la vélocité agrège tout ce qui n'est pas comparable : un point
n'est pas une valeur livrée. Une équipe peut très bien avoir une vélocité qui
augmente pendant que la valeur délivrée, elle, plafonne ou régresse.

La seule question qui m'intéresse, c'est : est-ce qu'on livre, en valeur,
ce qu'on avait prévu de livrer ? La vélocité ne répond pas à cette question.
C'est pour ça que je m'en méfie.

Et il y a une autre raison, toute pratique : la vélocité est hyper sensible à
la disponibilité de l'équipe et aux événements « extérieurs ». Une personne
en vacances, un incident, une période d'onboarding, une semaine de
conférences : tout ça fait chuter la vélocité sans qu'on ait rien changé à
notre façon de travailler. Difficile, dans ces conditions, d'en tirer des
analyses directes. À la limite, elle ne raconte que des variations, pas des
causes.

Ce que je regarde vraiment : le cycle time

« Le throughput, franchement, pas trop. Le cycle time en médiane et en
moyenne, oui, si je regarde. » (moi, en résumant ce que je regarde au
quotidien)

Si je devais ne garder qu'une famille de métriques, ce serait le temps. Le
lead time (déjà vu) mesure le temps entre l'idée et la livraison. Le cycle
time, lui, mesure le temps entre le début du travail sur un sujet et sa
mise en production. Deux angles proches, mais le cycle time a l'avantage de
commencer là où l'équipe a réellement la main.

Le throughput, c'est-à-dire combien d'éléments on livre par unité de temps,
je le regarde très peu. Il raconte un volume brut, sans rien dire de la valeur ni
de la difficulté. À l'inverse, je surveille le cycle time, et je le regarde
de deux façons complémentaires :

la médiane, qui me dit ce qui se passe pour le sujet « typique » de l'équipe, sans être perturbée par les extrêmes ;
la moyenne, qui, elle, est sensible aux valeurs extrêmes : si elle s'envole pendant que la médiane reste stable, c'est le signe qu'il existe des sujets coincés quelque part, qui prennent un temps anormal.

Confronter les deux, c'est un réflexe simple qui en dit long : une médiane
basse avec une moyenne haute, c'est la signature d'un backlog où quelques
sujets traînent depuis des semaines pendant que le reste avance vite.

Quelques sujets très lents tirent la moyenne vers le haut, pendant que la médiane reste basse : la signature d'un backlog avec des sujets coincés.

Le vrai temps de release : deploy + rollback

« Ok tu déploies en 10 min mais il te faut combien de temps pour rollback ?
C'est automatisé ? » (Kenny Dits,
mon chef)

Cette question de Kenny m'a marqué, parce qu'elle déplace le vrai sujet. On a
tous tendance à juger une livraison sur la rapidité du déploiement : « on
déploie en dix minutes ». Sauf que le temps de release ne se limite pas au
deploy. Il faut y ajouter tout ce qu'il faut pour revenir en arrière si
quelque chose ne va pas : le rollback.

Un déploiement en dix minutes sans rollback automatisé, c'est un déploiement
qui peut vous coûter une soirée entière. C'est cette logique qu'il faut
intégrer : le vrai temps de release, c'est deploy + rollback. Et un
rollback n'est un vrai filet de sécurité que s'il est automatisé, au même
titre que le deploy, et pas une procédure manuelle qu'on redécouvre dans
l'urgence.

J'en tire une règle simple que j'applique aux créneaux de mise en
production : si quelqu'un de l'équipe libère à 18 h 30 et que le temps total
(deploy + rollback) est d'une heure, alors il faut s'attendre à pouvoir être
occupé jusqu'à 19 h 30. Autrement dit, une release, on la place en
connaissant le pire cas, pas le meilleur.

On place une release en connaissant le pire cas (deploy plus rollback), et non en se fiant au temps de deploy seul.

Le deploy frequency et mon rapport au déploiement continu

Des métriques DORA¹, celle que j'exploite principalement, c'est la
deploy frequency : la fréquence à laquelle on met en production. C'est la
plus parlante pour l'équipe, parce qu'elle raconte directement le rythme de
livraison, celui qu'on ressent au quotidien.

Cela dit, je n'applique pas le modèle « déploiement continu à chaque merge
sur la branche principale » de façon dogmatique. C'est un très bon objectif
dans beaucoup d'équipes, mais ce n'est pas une fin en soi. Ma préférence, et
je l'assume, c'est plutôt un déploiement régulier à chaque Mesure
(cette unité de temps dont je parlais dans l'article précédent), après une
démo aux stakeholders pour valider les développements.

Concrètement : on développe pendant la Mesure, on présente ce qui est prêt
aux parties prenantes, et c'est après cette validation qu'on déploie. La
fréquence est donc régulière et prévisible, mais elle est pilotée par un
moment de validation humaine plutôt que par chaque merge. Ça colle mieux à la
façon dont je veux que l'équipe avance : livrer souvent, mais en sachant ce
qu'on livre et pourquoi.

Ce choix a aussi un effet d'entraînement sur les parties prenantes. Un
déploiement régulier, à un rythme connu, habitue tout le monde au fait que ce
rythme existe, et crée une forme de confiance dans le « ça sort à la prochaine
Mesure ». Ça prendra quelques mois, mais ce rythme finit par être compris
par l'équipe et autour de l'équipe, et surtout, il évite les sempiternelles
questions du « quand est-ce que ça sort ? ». On sait, et on le sait ensemble.

Enfin, déployer souvent présente deux avantages que je ne veux pas perdre de
vue. D'abord, cela permet de détecter les régressions plus vite : moins il y
a d'écart entre ce qu'on livre et la production, plus il est facile de
remonter à l'origine d'un problème. Ensuite, cela engage moins à chaque
release, tout simplement parce qu'on lance moins de code en production à
chaque fois. Le rythme régulier à chaque Mesure n'est donc pas en
contradiction avec ces bénéfices : il les garde, tout en introduisant le
moment de validation qui me semble indispensable.

Pour fixer ce rythme, une mise en garde : plutôt que de vous donner un
objectif non SMART du type « déployer plus souvent », donnez-vous un rythme
précis et soutenable, et tenez-vous y. Un rythme qu'on tient sur la durée
vaut toujours mieux qu'une ambition qu'on abandonne au bout de deux
semaines.

Et quand vous voulez améliorer le temps de déploiement, pensez à toute la
chaîne deploy + rollback, pas seulement au geste de déploiement en lui-même.
Identifiez l'étape qui prend le plus de temps et attaquez-vous à elle en
priorité : c'est là que vous gagnerez le plus. Pour donner un ordre de
repère, un temps de deploy + rollback viable, pour moi, c'est moins de
trente minutes.

La rétro radar, pour suivre le qualitatif

Les métriques techniques disent beaucoup du rythme et de la stabilité, mais
elles sont muettes sur l'essentiel : comment les gens se sentent dans
l'équipe. C'est là qu'intervient la rétro radar, le format de
rétrospective en radar
que Caroline Le Lay, une
amie et ancienne collègue, m'a fait découvrir. Je la fais environ tous les
six mois, et je la trouve très intéressante pour mesurer l'évolution
qualitative et humaine de l'équipe.

Le principe est simple. On définit des axes, chacun représentant une
dimension de la vie d'équipe. Chez moi, ils sont dix : collaboration, fun,
apprentissages, mission, ownership, process, ressources, rôles, vitesse et
valeur. À chaque itération, chaque membre se positionne sur ces axes, et on
reporte les résultats sur un radar : plus on est loin du centre, plus la
dimension est au vert.

Chaque axe correspond à une question précise sur la santé de l'équipe :

Axe	Ce que ça mesure
Collaboration	Une communication constante et de qualité, respectueuse.
Fun	Une ambiance agréable, le plaisir à travailler ensemble.
Apprentissages	Des compétences qui progressent, itération après itération.
Mission	L'alignement sur les objectifs de l'entreprise et la création de valeur.
Ownership	L'autonomie, la capacité à décider par soi-même.
Process	Des processus qui aident à créer de la valeur, sans ralentir ni bloquer.
Ressources	L'accès aux moyens matériels et au support nécessaires.
Rôles	Des rôles et responsabilités clairs, toutes les compétences présentes.
Vitesse	De la valeur produite en respectant les dates, à un rythme sain.
Valeur	Une valeur mesurable, quantifiable et réalisable par l'équipe.

Un détail pratique qui change tout : j'envoie le formulaire à l'avance. Si
chacun remplit son positionnement avant la séance, la rétro elle-même ne sert
plus à collecter des réponses, mais uniquement à échanger, à prendre des
notes sur les résultats, et à définir ensemble des actions. On gagne un temps
précieux et on garde la séance pour ce qui compte : la discussion et les
décisions, pas la saisie.

L'intérêt n'est pas tant la forme du radar à un instant t que son évolution
d'une itération à l'autre. On superpose le radar de la fois précédente et
celui du jour : ce qui s'agrandit, ce qui se rétracte, ce qui se dégrade
sans qu'on l'ait vu venir. C'est un excellent détecteur précoce : une
dimension qui se dégrade discrètement pendant deux itérations mérite qu'on
s'y attarde avant que ça ne devienne un problème.

On ne lit pas le radar comme un absolu, mais comme une évolution d'une itération à l'autre.

Un squelette d'axes que vous pouvez adapter :

# Rétro radar · Mesure du AAAA-MM-JJ

| Axe            | Position (1 à 5) | Commentaire |
| -------------- | ---------------- | ----------- |
| Collaboration  | …                | …           |
| Fun            | …                | …           |
| Apprentissages | …                | …           |
| Mission        | …                | …           |
| Ownership      | …                | …           |
| Process        | …                | …           |
| Ressources     | …                | …           |
| Rôles          | …                | …           |
| Vitesse        | …                | …           |
| Valeur         | …                | …           |

Comme pour le journal de bord et le brag document vus dans le deuxième
article, l'important est de consigner : c'est en superposant les relevés
successifs qu'on voit l'évolution, pas en se fiant à la mémoire de « ce
qu'on ressentait la dernière fois ».

Regarder les tendances, pas les absolus

Une dernière chose, peut-être la plus importante. Ce que j'évite avec les
métriques, c'est de les regarder comme des absolus. Un chiffre isolé ne veut
pas dire grand-chose : « notre cycle time est de cinq jours » n'a de sens
que comparé à ce qu'il était il y a un mois, ou à ce qu'on s'était fixé.

Je regarde donc surtout les tendances et les évolutions. Est-ce que ça
s'améliore, est-ce que ça se dégrade, est-ce que ça stagne ? C'est la pente
qui m'intéresse, pas la valeur. Une métrique qui se dégrade légèrement mais
dont on connaît la cause est bien moins inquiétante qu'un chiffre stable
dont plus personne ne se demande pourquoi il est ce qu'il est.

Et surtout, une métrique ne doit jamais devenir une cible à atteindre à
tout prix : sinon elle cesse de mesurer la réalité et commence à la
déformer². Le jour où un chiffre devient un jugement sur les
personnes plutôt qu'un instrument de compréhension, il faut savoir le
ranger. C'est le meilleur garde-fou que je connaisse.

Et la suite ?

Il reste d'autres aspects des métriques que je n'ai pas abordés ici. Si vous
voulez que je précise un point ou que j'aborde un thème en particulier, mes
réseaux sont accessibles depuis ce blog : écrivez-moi, je serai ravi de vous
lire.

Le prochain épisode portera sur le recrutement, l'onboarding et
l'offboarding, un sujet que j'ai déjà évoqué en passant dans le deuxième
article. Comme toujours, vous pouvez retrouver l'ensemble de la série via le
tag engineering-management.

Notes

Les métriques DORA (DevOps Research and Assessment) regroupent quatre indicateurs de performance : la deploy frequency, le lead time, la change failure rate et le mean time to recovery. Stéphane Robert les présente très bien sur son blog : DORA, les métriques devops.
C'est la loi de Goodhart : quand une mesure devient une cible, elle cesse d'être une bonne mesure.

Engineering manager : donner des objectifs et de la vision

Antoine Caron — Thu, 15 Oct 2026 17:15:26 +0000

Cet article a été publié initialement sur mon blog.

C'est le troisième article de ma série sur ce que le rôle d'engineering
manager m'a appris. Comme pour les épisodes précédents, ce qui suit n'est
ni une méthode ni une vérité générale : c'est un retour d'expérience
personnel, structuré autour des citations et des principes que des
personnes qui ont compté dans mon parcours m'ont transmis, et de ce qu'ils
m'apportent au quotidien.

Le premier épisode portait sur le rôle et la posture d'engineering
manager, le deuxième sur le
1:1 et le suivi individuel.
Vous pouvez retrouver tous les articles de la série sur la page du tag
engineering-management.

Ce billet-ci se concentre sur les objectifs et la vision : comment se
donner des horizons de travail, comment les faire vivre dans le temps, et
comment les rendre compréhensibles par toute l'équipe.

Se donner des horizons

« Un auteur sans deadline, c'est juste un mec au chômage. » (Kyan
Khojandi, entendu dans une interview)

Il existe, pour moi, trois types de projets : ceux drivés par une date,
ceux drivés par un résultat attendu, et ceux drivés par les deux à la fois.
Ce troisième cas est de loin le plus inconfortable : si vous savez
exactement ce que vous voulez livrer, il devient très compliqué d'imposer
en plus une date fixe, sans risquer soit le retard, soit un scope amputé
pour tenir les délais.

La question à garder en tête en permanence, c'est : est-ce que l'important
c'est que ça sorte à telle date, quitte à ce que le scope bouge ? Ou est-ce
que l'important c'est ce qui doit sortir, quitte à ce que la date bouge ?
Un projet sans réponse claire à cette question navigue à vue.

Se donner des dates et des jalons, ce n'est pas de la rigidité gratuite :
c'est se forcer à se demander régulièrement « comment je peux rapidement
délivrer un truc qui marche, que je peux montrer ? ». On touche là au cœur
de l'agilité et de la création de valeur. Et l'inverse est tout aussi vrai
: si vous n'avez pas d'ambition de date de fin pour un projet, ne soyez pas
surpris s'il ne finit jamais. C'est la loi de Parkinson : un travail
s'étend jusqu'à occuper tout le temps disponible pour son achèvement.

Pour fixer ces horizons, je recommande de s'aligner sur le calendrier de
l'entreprise. Si elle revoit ses objectifs tous les six mois, construire
des projets qui tiennent sur six mois est une bonne idée ; pareil pour
trois mois, ou pour quatre semaines. Appelons ça, comme en musique, la
Mesure¹ : l'unité de temps qui rythme le travail de l'équipe. La
question qui en découle, à se poser à chaque nouvelle Mesure : « qu'est-ce
qu'on peut faire de mieux pour répondre à ce problème en X semaines ? »

La macula : net de près, flou de loin

« Construire une roadmap sur six mois ou un an, ce n'est pas savoir
exactement ce qu'on fera dans six mois ou un an, c'est définir ce qu'on
fait demain et dans quelle direction on va. » (plusieurs coachs Agile
avec qui j'ai travaillé)

C'est l'image que je préfère pour parler de roadmap : celle de la macula,
cette petite zone au centre de la rétine qui capte le détail net, entourée
d'une vision périphérique bien plus floue. D'abord avoir une vision claire
du mois prochain, avant d'essayer de savoir précisément ce qu'on fera dans
six mois. Se laisser de la place sur le moyen et le long terme, plutôt
que de prétendre à une précision qu'on n'a pas.

Comme la vision humaine : net au centre, de plus en plus flou vers la périphérie. La roadmap fonctionne pareil.

Expliquer ce qu'on va faire est important, mais exprimer pourquoi on va le
faire, en quoi c'est nécessaire, est un besoin tout aussi fort — j'y
reviens dans la section sur la répétition, un peu plus loin.

Il y a un moment où cette netteté se rejoue : la bascule d'une Mesure à la
suivante. C'est souvent là qu'il faut consacrer plus de temps que
d'habitude, en deux temps. D'abord faire les comptes de la Mesure qui se
termine : est-ce que les objectifs sont atteints, est-ce qu'on a fini ce
qu'on voulait faire. Ensuite regarder ce qu'on veut faire dans la
suivante, et le valider avec l'équipe. On ne bascule pas une Mesure en
mode automatique ; on la clôt, puis on en ouvre une nouvelle.

Mesurer le lead time

« Ça fait quatre ans qu'on parle de ce projet, donc on va pas parler de
lead time. » (un ancien collègue, anonyme — la formule fait toujours
mouche)

Le lead time, c'est le temps écoulé entre le moment où un sujet est
identifié et le moment où il est réellement livré. C'est une mesure
implacable : elle ne s'intéresse pas à combien de temps vous avez
« vraiment » travaillé dessus, seulement à combien de temps il a fallu à
l'idée pour devenir réalité.

Je tiens, de mon côté, une petite liste personnelle où je note et je
mesure le lead time des projets de mon équipe. Ce n'est pas un outil de
flicage : c'est un instrument de calibrage. Mon objectif en tant
qu'engineering manager, c'est que la médiane des lead time de mon équipe
reste inférieure à la Mesure de temps de l'entreprise vue plus haut. Si
l'entreprise raisonne à six mois et que la médiane de mes projets dépasse
six mois, quelque chose ne va pas dans la façon dont je les découpe ou dont
je les priorise — et la citation ci-dessus finit tôt ou tard par devenir
vraie dans ma propre équipe.

Répéter et multiplier les formats

« Monsieur, qu'est-ce qu'il faut faire déjà ? » (mes étudiants, à
l'époque où je donnais des cours à la fac)

Donner des cours m'a appris quelque chose que j'ai réemployé sans arrêt en
tant que manager : pour qu'une information soit transmise et vraiment
comprise, il faut la répéter, et la répéter sous des formats
différents. Une seule annonce, un seul support, ne suffit jamais — même
quand on a l'impression d'avoir été parfaitement clair la première fois.

Concrètement, pour la vision et les objectifs, je fais vivre la même
information sous plusieurs formes :

une réunion en fin de Mesure pour présenter et discuter la suivante ;
en 1:1, une question que je pose régulièrement à chacun : « est-ce que tu vois où on va ? est-ce qu'il y a un projet, chez nous, qui te semble pas clair ? » ;
la roadmap elle-même, partagée et mise à jour régulièrement, au format image — un visuel qu'on peut regarder d'un coup d'œil vaut mieux qu'un document qu'il faut rouvrir pour se souvenir où on en est.

Petite parenthèse : c'est en cherchant justement ce format visuel, simple
à tenir à jour, que j'ai fini par construire mon propre petit outil de
roadmap, disponible ici : roadmap.slashgear.dev.

Vous remarquerez que cet exemple applique lui-même le principe de la
macula vu plus haut : beaucoup de détail confirmé sur le mois en cours,
un peu moins sur le trimestre suivant, et un unique bandeau flou « scope
TBD » pour le second semestre.

SMART, et le piège du silo

« Un objectif malin, c'est SMART. »
(Caroline Le Lay)

Un petit rappel s'impose : un objectif SMART est Spécifique,
Mesurable, Atteignable, Réaliste (ou pertinent) et Temporel.
« Améliorer la qualité » n'est pas un objectif SMART ; « réduire de 30 % le
nombre de tickets de support ouverts par mois d'ici la fin de la Mesure »
en est un. La différence, c'est qu'on sait, sans ambiguïté possible, quand
il est atteint.

Un exemple vécu : quelqu'un dans l'équipe se plaint de porter trop de
tickets de bug tout seul, et aimerait que ça se répartisse mieux.
L'équipe se fixe alors comme objectif de « mieux répartir les tickets de
bug ». Pas très SMART : comment sait-on, concrètement, qu'on l'a atteint ?

Une première piste pour le rendre SMART : que chacun traite au moins un
ticket de bug par Mesure. Juste un ? Ça paraît dérisoire, dit comme ça.
Mais si la situation de départ, c'est zéro ticket de bug traité par la
moitié de l'équipe, passer de zéro à un pour tout le monde, franchement,
ça paraît déjà pas mal, non ? C'est un objectif atteignable, sur lequel
personne ne peut dire « ça ne me concerne pas » — et rien n'empêche de
relever la barre à la Mesure suivante une fois que ce premier palier
est acquis.

Mais définir un objectif SMART ne dit rien de qui le porte, et c'est là que
se cache le vrai piège. Je préfère, autant que possible, donner des
objectifs à l'équipe plutôt que des objectifs individuels. Un objectif
individuel a tendance à siloter le travail : chacun défend son bout de
périmètre, et l'entraide en pâtit, parfois sans même qu'on s'en rende
compte. Un objectif d'équipe pousse au contraire tout le monde à avancer
ensemble, à s'entraider pour l'atteindre, plutôt qu'à optimiser
chacun dans son coin.

Concrètement, sur un même sujet, ça peut donner deux objectifs tout aussi
SMART l'un que l'autre, mais avec des effets opposés :

À éviter — objectif individuel : « Chaque développeur ferme au moins 15 tickets de support par Mesure. » Chacun va naturellement piocher les tickets faciles pour faire son quota ; le ticket compliqué qui traîne depuis trois semaines, personne n'y touche, puisqu'il ne rapporte rien à personne en particulier.
À privilégier — objectif d'équipe : « L'équipe réduit de 30 % le nombre de tickets de support ouverts par mois d'ici la fin de la Mesure. » Peu importe qui ferme quoi : seul le chiffre global compte, donc s'entraider sur le ticket compliqué devient rationnel plutôt que perçu comme du temps perdu.

Même chose sur un projet plus large :

À éviter — objectif individuel : « Le lead technique livre la migration vers la nouvelle API de paiement. » Un seul point de défaillance : si cette personne part en vacances, change d'équipe ou tombe malade, le projet s'arrête net, et personne d'autre n'a le contexte pour reprendre.
À privilégier — objectif d'équipe : « L'équipe a basculé 100 % du trafic de paiement vers la nouvelle API d'ici la fin du trimestre. » N'importe qui peut reprendre la suite, parce que le contexte est partagé dès le départ plutôt que concentré dans une seule tête.

Pas de ticket pour dans six mois

« Écrire un ticket pour un sujet potentiel à faire dans six mois, c'est
globalement toujours une mauvaise idée. »
(Emmanuel Hervé)

Le coût de maintenance d'un ticket ouvert pour dans six mois est énorme,
même à l'ère de l'IA qui promet d'en absorber une partie. On finit avec un
backlog de 600 tickets, dont certains ont deux ou trois ans, et dont plus
personne ne connaît vraiment le détail. Un backlog de 2 000 tickets
n'est pas une roadmap : c'est un cimetière d'intentions.

Si un sujet est vraiment important, il reviendra. Pas besoin de lui
réserver une place dans le backlog pour ça. Ce que je fais à la place :
noter l'idée dans une page « boîte à idées », pas dans un vrai ticket. Ça
évite le coût de maintenance, tout en gardant une trace suffisante pour la
retrouver le jour où le sujet redevient d'actualité.

Construire une roadmap, ça demande justement de s'extraire des sujets du
quotidien pour aller enquêter sur les véritables enjeux de l'entreprise.
Et côté technique, c'est aussi accepter de trancher : décider sur quoi on
choisit d'investir, et donc, implicitement, sur quoi on choisit de ne pas
investir tout de suite.

Un squelette de boîte à idées que vous pouvez copier tel quel :

# Boîte à idées

| Idée | Notée le   | Contexte | Statut                              |
| ---- | ---------- | -------- | ----------------------------------- |
| …    | AAAA-MM-JJ | …        | à explorer / abandonnée / en Mesure |

Et la suite ?

Il reste d'autres aspects des objectifs et de la vision que je n'ai pas
abordés ici. Si vous voulez que je précise un point ou que j'aborde un
thème en particulier, mes réseaux sont accessibles depuis ce blog :
écrivez-moi, je serai ravi de vous lire.

Le lead time n'est qu'une métrique parmi d'autres : le prochain épisode
portera sur les métriques que je surveille en tant qu'engineering
manager, pour aller plus loin. Comme toujours, vous pouvez retrouver
l'ensemble de la série via le tag
engineering-management.

Notes

Mesure : terme que j'emploie ici comme en musique, pour désigner l'unité de temps qui se répète et rythme le travail de l'équipe (un mois, un trimestre, six mois — selon le calendrier de l'entreprise). Une Mesure n'est pas un sprint : c'est l'horizon sur lequel se fixent les objectifs, avant de faire les comptes et d'en ouvrir une nouvelle.

Engineering manager : le 1:1 et le suivi individuel

Antoine Caron — Thu, 15 Oct 2026 17:11:47 +0000

Cet article a été publié initialement sur mon blog.

C'est le deuxième article de ma série sur ce que le rôle d'engineering
manager m'a appris. Comme pour le premier épisode, ce qui suit n'est ni une
méthode ni une vérité générale : c'est un retour d'expérience personnel,
structuré autour des citations et des principes que des personnes qui ont
compté dans mon parcours m'ont transmis, et de ce qu'ils m'apportent au
quotidien.

Le premier épisode portait sur le rôle et la posture
d'engineering manager ; si vous
ne l'avez pas lu, c'est une bonne entrée en matière avant celui-ci. Vous
pouvez aussi retrouver tous les articles de la série sur la page du tag
engineering-management.

Ce billet-ci se concentre sur le 1:1 et le suivi individuel : ce temps
dédié, régulier, en tête-à-tête avec chaque personne de l'équipe, et tout ce
qui se joue autour pour accompagner les individus dans la durée.

Le paradoxe de la porte ouverte

« Ma porte est toujours ouverte. » (une phrase que j'ai entendue de la
bouche de plusieurs managers, que je ne citerai pas ici)

Annoncer que sa porte est ouverte, ce n'est pas si généreux qu'il n'y
paraît. Au fond, cela ne fait qu'ériger en principe le « venez me déranger
quand vous en avez besoin » : la charge de provoquer l'échange repose
entièrement sur le managé. Dans une petite équipe, ça peut suffire. Passé
une certaine taille, ça ne tient plus.

En cas d'urgence ou de situation qui le réclame, votre porte doit
évidemment rester ouverte. Mais une disponibilité permanente n'est pas un
dispositif de suivi : c'est un modèle qui ne passe pas à l'échelle, et qui
laisse de côté ceux qui ne viennent jamais frapper.

La réponse, c'est d'instaurer un rendez-vous régulier avec chaque personne
de l'équipe : un temps dédié, qui vous revient d'initier, pour échanger,
prendre la température et vous donner mutuellement du feedback.

La porte ouverte laisse les sollicitations arriver n'importe quand ; le 1:1 régulier les rassemble dans un temps prévu pour ça.

Une régularité par individu

« Tu veux qu'on se voie à quelle régularité ? »
(Florent Dubost,
mon manager pendant plusieurs années)

Tout est affaire d'individu. Chacun a besoin de voir son manager à une
fréquence et pour une durée qui lui sont propres. Décréter « je vois
tout le monde trente minutes toutes les deux semaines », c'est la garantie
de ne répondre au besoin de personne : certains étoufferont, d'autres
tourneront en rond faute de matière.

Cette cadence se négocie donc avec chaque managé. Elle n'a rien de figé et
peut évoluer au fil du temps, mais une fois posée, elle devient un
engagement : on ne l'annule pas, on la décale.

Concrètement, je recommande de fixer explicitement, en échangeant avec la
personne, la fréquence et la durée du 1:1, puis de les consigner quelque
part. Un accord tacite se perd ; un accord écrit se relit et se révise
quand le besoin change.

Le cas des alternants, stagiaires et profils juniors

« Je ne sais pas si je suis suffisamment à l'aise pour prendre un
alternant… » (un collègue, en pleine crise de confiance)

Le suivi des profils en apprentissage fait souvent peur : celle de mal s'en
occuper, ou celle d'être sollicité en permanence. J'ai eu la chance de
donner des cours, et l'expérience d'une classe de quarante étudiants qui
vous demandent chacun à leur tour « il faut faire quoi, monsieur ? » forge
assez vite l'envie de se doter d'une stratégie.

Comme pour n'importe quel managé, la réponse passe par un suivi régulier,
mais nettement plus soutenu. Ce que j'ai appliqué le plus souvent : deux
créneaux d'une heure par semaine, bloqués dans le calendrier, généralement
un le mardi et un le jeudi, pendant lesquels je leur consacre du temps pour
avancer ensemble sur leur sujet. Ces points réguliers créent des
respirations dans la semaine : la personne sait qu'un moment est prévu pour
poser ses questions et ses blocages, ce qui évite les sollicitations
permanentes. C'est aussi ce qui rend possible l'accompagnement de plusieurs
apprenants en parallèle : votre capacité, c'est le temps que vous êtes prêt
à bloquer chaque semaine.

Un autre réflexe utile : confier deux sujets à la fois. Le premier, « l'os »,
est le sujet difficile, celui sur lequel la personne peut rester coincée.
Le second est un sujet sans blocage connu, sur lequel elle peut continuer à
avancer librement quand l'os résiste. Elle n'est jamais complètement à
l'arrêt, et vous n'êtes pas le seul goulot d'étranglement de sa semaine.

L'arrivée d'un alternant ou d'un stagiaire, ça se prépare. J'y reviendrai
plus en détail dans un article dédié à l'onboarding, l'offboarding et le
recrutement.

Avec Jules Poissonnet, mon ancien alternant, sur la scène de LyonJS 100
pour un talk sur les stratégies de test. Accompagner un profil junior, c'est
aussi l'amener jusqu'à partager devant une salle.

Étaler ses 1:1 dans la semaine

Qu'il s'agisse des 1:1 de vos managés ou de vos apprenants, placez-les dans
un agenda partagé. Pourquoi pas un agenda dédié, avec sa propre couleur,
pour visualiser d'un coup d'œil comment vos entretiens se répartissent. Le
but est d'éviter la journée entièrement remplie de 1:1. Certains préfèrent
tout enchaîner ; pour moi, ce serait un vrai cauchemar.

Un 1:1 demande une écoute pleine et entière. En enchaîner cinq dans la même
journée, c'est arriver au dernier vidé de son attention, à écouter à moitié
la personne qui n'y est pour rien si elle passe en fin de liste. Chaque
entretien laisse aussi du travail derrière lui : une note à prendre, une
relance à faire, un sujet difficile à digérer avant de pouvoir passer à
autre chose. Il faut un peu d'air entre deux pour ça. Enfin, espacer les
1:1 leur laisse la souplesse de déborder : si l'un a besoin d'un quart
d'heure de plus, il ne fait pas s'effondrer les quatre suivants.

Une semaine type : un 1:1 par jour, à des horaires différents, plutôt qu'une demi-journée entière d'entretiens enchaînés.

Des besoins qui ne s'équilibrent pas

« Il est normal que certaines personnes de vos équipes nécessitent un
accompagnement plus fort que d'autres. » (Sarah Drasner, dans le livre
cité dans l'article
précédent)

Ça peut être frustrant quand on débute dans le rôle, mais avec l'expérience,
ça devient une évidence. Chaque personne de l'équipe est différente, et
l'accompagnement que vous lui apportez n'est ni le même ni comparable d'un
individu à l'autre. Oui, vous aurez peut-être quelqu'un qui occupera à lui
seul la moitié de votre temps de management sur une semaine. Avec le recul,
ça ne me choque plus.

Et tout cela évolue. Une personne que vous suivez de loin à un moment donné
sera peut-être bien plus demandeuse l'année suivante. Rien n'est
nécessairement corrélé à l'expérience ou à l'autonomie du managé : un profil
junior vous mobilisera souvent davantage, mais vous croiserez aussi des
juniors qui gagnent très vite en autonomie et se jettent dans les ronces
avec appétit pour apprendre. Dans ce cas, laissez-les faire.

Ne soyez donc pas surpris que les besoins soient déséquilibrés dans
l'équipe. Cherchez l'équité, pas l'égalité : donnez plus à celles et
ceux qui en ont le plus besoin. C'est à vous de vous adapter à l'équipe,
pas l'inverse.

Un exemple : sur une semaine, une personne peut mobiliser la moitié de votre temps de management, une autre à peine 5 %. C'est normal.

Le syndrome du sauveteur compulsif

« Des fois j'y arrive, souvent j'me trompe, donc j'recommence, et puis
j'apprends. » (Orelsan — et pourquoi pas Dorothée tant qu'on y est ? je
cite qui je veux, hein)

Quand on reçoit la responsabilité de manager, on a envie de protéger son
équipe, de lui éviter les erreurs dans lesquelles on est soi-même tombé.
L'intention est louable, mais elle prive l'équipe de l'essentiel de son
apprentissage. L'image que je me fais du rôle, c'est plutôt : « je dois
laisser mon équipe échouer pour qu'elle progresse. » C'est frustrant.

Certains managers se diront « si je le fais moi-même, j'en ai pour dix
minutes ». En réalité, vous en avez pour dix minutes plus vos années
d'expérience. La personne que vous managez, elle, n'a pas ces années :
elle est en train de les construire. Laissez-la échouer.

Vous allez me trouver vilain, mais il m'est arrivé de créer sciemment des
situations où je « soulève légèrement le tapis » pour qu'une personne de
l'équipe s'y prenne les pieds. Rassurez-vous, c'est une image : mon équipe
n'est pas sponsorisée par les crèmes à l'arnica. Provoquer des situations
qui font grandir l'équipe fait partie du rôle. C'est dans une certaine zone
d'inconfort que vos managés apprennent et progressent, pas en refaisant ce
qu'ils maîtrisent déjà.

Votre alarme interne doit évidemment continuer de sonner : il s'agit
d'éviter que l'équipe échoue trop fort, ou se fasse vraiment mal. Pour
distinguer l'incident formateur du vrai problème, je me sers d'un test
simple : si je m'imagine y repenser dans deux ans et que je le trouve
encore grave à ce moment-là, alors il est grave aujourd'hui et je dois
intervenir. Sinon, je laisse faire.

Tenir un journal de bord

« Journal de bord : mer calme, embarquement de 4 passagers, vent NE
force 3… » (pas la citation d'un mentor cette fois, juste l'image qui m'a
servi de modèle)

L'image en tête de cet article est une double page du livre de bord de la
frégate néerlandaise Medea, tenu en 1786 par son commandant A.A. Buyskes
(Nationaal Archief, domaine public). On y
voit des profils de côtes dessinés à main levée et le relevé quotidien de la
navigation : cap, vent, mouillages, incidents. Des siècles avant nos outils
de suivi, la pratique était déjà là — noter chaque jour, factuellement, ce
qu'on observe, pour pouvoir s'y reporter plus tard. C'est exactement l'usage
que je vous propose d'en faire avec votre équipe.

Avant même de parler du document qui me sert à structurer le suivi de mes
managés, il y a un préalable : disposer quelque part d'un espace de notes.
Vous observez votre équipe en continu, dans ses réussites comme dans ses
ratés, à l'échelle collective comme individuelle. Avec une petite équipe, on
a vite envie de s'en remettre à sa mémoire ; elle finit toujours par être
débordée.

Je conseille donc de tenir un journal de bord : un endroit où consigner les
événements de la vie de l'équipe. Il vous est strictement personnel, et sa
seule contrainte est de vous obliger à rester factuel.

On peut y noter la mise en production d'une fonctionnalité, un incident, la
réussite marquante d'une personne, une communication qui est mal passée, un
oubli de standup, ou encore une période où quelqu'un s'est visiblement
beaucoup investi. Relus quelques semaines plus tard, au moment d'un 1:1 ou
d'un point de carrière, ces faits datés valent bien mieux qu'une impression
générale.

Je vous montrerais bien le mien, mais comme je l'ai dit, il est privé. À
vous de faire le vôtre.

Des entrées courtes, datées et factuelles : ni interprétation ni jugement, juste ce qui s'est passé.

Le brag document : se souvenir de ses réussites

« Si on me demande quels sont mes succès de l'année, c'est très dur d'être
exhaustif. » (Anne-Laure de Boissieu, une ancienne collègue et amie)

Dans une conférence que je recommande
vivement, mon ancienne
collègue et amie Anne-Laure présente un concept que je ne connaissais pas et
qui m'a beaucoup servi depuis : le brag document.

C'est un document proche du journal de bord, à ceci près qu'il ne recense
que les fiertés, les sujets que l'on considère personnellement comme des
succès. Notre cerveau fonctionne ainsi : on oublie très vite ce dont on
devrait être fier, pendant que le problème sur lequel on bloque depuis deux
semaines occupe presque tout l'espace.

D'où l'intérêt de tenir un brag document avec chaque managé, et un autre
pour l'équipe dans son ensemble. Chaque personne y historise avec vous, au
fil de l'année, les fiertés qu'elle a eues : un titre, une date, une courte
description. À vous de faire le même exercice à l'échelle de l'équipe.

À quoi bon, me direz-vous ? Ce document se révèle précieux dans plusieurs
situations :

accompagner un membre de l'équipe en questionnement, qui n'a pas l'impression de progresser ou qui traverse un syndrome de l'imposteur ;
préparer les périodes d'évaluation annuelle en s'appuyant sur tous les succès de l'année, et pas seulement sur ceux des deux derniers mois ;
défendre l'impact et la vision de votre équipe dans l'entreprise.

Je ne rends pas justice ici à la richesse du talk d'Anne-Laure. Il vaut
vraiment le détour :

Donner du feedback

« Praise in public, feedback in private. » (Sarah Drasner)

Un manager passe une part énorme de son temps à donner du feedback. Je ne
vais pas détailler ici comment le formuler : le sujet mérite un article à
lui seul. Je m'en tiens à quelques clés que l'expérience, et la lecture du
livre de Sarah, m'ont fait comprendre.

Commençons par le feedback positif. Quand quelqu'un de votre équipe fait
quelque chose que vous trouvez franchement bien, vous devez le dire,
positivement, devant toute l'équipe. Et le redire lors du 1:1 suivant.

Pourquoi deux fois ? Parce que chacun des deux canaux, seul, laisse un
doute. En privé uniquement : « il me dit ça pour me faire plaisir, il ne le
pense pas vraiment ». En public uniquement : « il le dit devant tout le
monde, mais je ne sais pas ce qu'il en pense réellement ». Les deux
ensemble lèvent l'ambiguïté.

Tout cela suppose d'avoir noté ce qui s'est passé — c'est l'un des usages de
mon journal de bord. Des faits consignés factuellement, ce sont des
occasions de feedback prêtes à l'emploi. Et vous verrez qu'une personne
ajoute bien plus facilement une ligne à son brag document quand vous avez
commencé par reconnaître la chose vous-même.

C'est quand, la dernière fois que vous avez dit à quelqu'un de votre équipe
qu'il ou elle avait fait du bon travail ?

Vient ensuite le feedback plus difficile : les rectifications, les axes
d'amélioration.

Sur ce terrain, l'expérience m'a appris qu'il existe très peu de situations
qui justifient un feedback direct, sur le moment. La principale exception :
le danger immédiat. Si quelqu'un dit ou fait quelque chose qui peut nuire
directement à une autre personne, là, j'interviens tout de suite.

En dehors de ça, laisser le feedback mijoter est plutôt une bonne chose.
Qu'est-ce qui vous empêche de noter les faits et d'en reparler à froid lors
d'un prochain 1:1 ? Ce délai vous laisse réfléchir à la manière d'amener les
choses, et, la plupart du temps, il fait retomber la pression : « en fait,
ce n'est pas si grave ». Si un feedback ne vaut pas la peine d'attendre
une à deux semaines pour être donné, est-ce vraiment un feedback
pertinent ?

À l'inverse du feedback positif, celui-ci se donne uniquement en privé, dans
un échange en tête-à-tête avec la personne.

Les valeurs et les préférences

« Tu verras que la source première des conflits dans une équipe, ce sont
des conflits de valeurs. Et l'ego, bien sûr. »
(Kenny Dits)

Si les frictions naissent surtout d'un désaccord sur ce qui compte, alors
une partie du travail de suivi consiste à savoir ce qui compte pour chacun,
avant que ça ne coince.

Sarah Drasner propose pour cela un exercice tout simple dans son livre :
poser directement la question à vos managés, en 1:1. Trois questions
suffisent :

Dans ton travail, quelles sont les trois choses les plus importantes pour toi ?
Qu'est-ce que tu préfères faire ?
Qu'est-ce que tu aimes le moins faire ?

Rien qu'en posant ces questions, vous découvrirez que tout le monde ne
classe pas les choses dans le même ordre que vous. L'un vous parlera des
collègues et de l'ambiance, l'autre de la qualité du code, un troisième de
l'impact pour les utilisateurs, un quatrième de cohérence. C'est très varié.
Cet exercice vous fait mieux connaître les personnes de votre équipe et vous
évite de leur plaquer un archétype construit sur vous-même ou sur un autre
collègue.

Vous remarquerez aussi que certaines personnes n'évoquent pas du tout
certaines thématiques dans leur top 3. Ça ne veut pas dire que ça ne compte
pas pour elles, seulement que ce n'est pas leur priorité. Et ces
non-équivalences de priorité sont souvent à la racine des problèmes
d'équipe.

Imaginez Alex, « j'aime quand on règle vite les soucis des utilisateurs sans
trop débattre », et Sam, « j'aime quand on prend le temps de réfléchir au
problème pour trouver une solution qui répond parfaitement au besoin ».
Inutile de faire un dessin : Alex et Sam finiront par se retrouver en
tension. Mais si vous le savez, et que vous savez maintenant comment chacun
fonctionne, vous pouvez mettre un peu d'eau dans leurs vins respectifs et
trouver des compromis qui ménagent les valeurs des deux.

Le même exercice, deux classements très différents — et une préoccupation commune qui ne pèse pas du tout le même poids d'une personne à l'autre.

Cet exercice se fait en 1:1. Mais quand l'équipe est suffisamment à l'aise,
il devient aussi un bon jeu collectif : chacun arrive avec ses trois post-it
par question, on mélange le tout, et l'équipe doit retrouver quelle réponse
va à qui, et dans quel ordre.

Connaître les préférences, ensuite, ce n'est pas pour ne distribuer que des
tâches que chacun adore et cloisonner l'équipe. C'est pour savoir ce que les
gens aiment et ce qu'ils détestent. On a tous une jauge intérieure : elle se
vide quand on fait des choses qui nous pèsent, elle se recharge quand on
fait des choses qui nous plaisent. En connaissant les deux, vous pouvez
aider chacun à tenir cet équilibre.

Chacun porte cette jauge. Le travail de suivi, c'est de faire en sorte qu'elle ne tombe pas durablement à zéro.

Toutes ces réponses se rangent dans la page de suivi de la personne, et vous
y reviendrez : pour répartir les sujets, pour comprendre une tension, pour
vérifier de temps en temps que ce qui comptait il y a un an compte encore.

Suivre et encourager l'apprentissage

« Un jour j'ai monté un truc, les Last Friday Talks : une demi-journée
de conférences tech internes, le dernier vendredi du mois, pour que les
gens racontent ce qu'ils font. Dès la deuxième édition ce n'était plus le
dernier vendredi, mais peu importe. »
(Kenny Dits — encore lui)

Le manager a le devoir d'accompagner l'apprentissage de son équipe, sur deux
axes qui vont ensemble : s'assurer que chacun a le temps et les moyens
d'apprendre, et s'assurer que personne ne se disperse.

J'ai fini par en faire un petit rituel. On liste ensemble, dans un tableau,
les sujets de veille technique que la personne veut explorer, avec pour
chacun : le sujet, son état, la date de départ, une durée estimée, une
courte description et un pourcentage d'avancement. Tout y passe : des
conférences à voir en replay, des articles à lire, des proof of concept
d'outils ou de technos, des formations, des certifications.

Un extrait, colonne description mise de côté pour la lisibilité :

Sujet	État	Départ	Durée est.	Avancement
Talk « Local-first » dotJS	partagé	2026-02-10	2 h	100 %
PoC OpenTelemetry	terminé	2026-01-15	1 j	100 %
Rust pour l'embarqué	en cours	2026-03-02	3 j	60 %
Certification CKA	demandé	—	5 j	0 %

Une seule règle : on ne démarre un sujet que s'il n'y en a pas déjà deux en
cours. Autrement dit, pour en commencer un nouveau, il faut d'abord en
terminer un, ou l'abandonner assumé.

Les états possibles : demandé, rejeté (très rare — sauf si quelqu'un
vous annonce qu'il aimerait apprendre le saut en parachute), en cours,
terminé, et partagé.

Ce dernier état est le plus important. Pour moi, un apprentissage n'est
vraiment terminé que lorsqu'il a été partagé : à l'équipe, à la guilde, à
la communauté. C'est là que la citation de Kenny prend tout son sens — un
espace de partage régulier, même bancal, même plus vraiment le dernier
vendredi du mois, donne une destination à tout ce travail de veille.

Je dois avouer qu'une fois le principe bien ancré et adopté par l'équipe, le
suivi dans le tableau n'est plus vraiment nécessaire. Mais il aide à poser
les bases.

Le template de page de suivi individuel

Tout ce qui précède se range quelque part. Ce que j'ai fini par construire,
c'est une page unique par managé — un hub de suivi. Chez moi elle vit dans
Confluence, mais Notion, un Google Doc ou n'importe quel autre outil font
tout aussi bien l'affaire. Le point important : elle n'est accessible qu'à
deux personnes, la personne concernée et moi.

Elle rassemble, au même endroit :

l'identité et la date d'arrivée ;
les valeurs et préférences : le top 3 de ce qui compte, les sujets préférés, les sujets moins aimés ;
le brag document : titre, date, description ;
l'apprentissage supervisé : le tableau vu plus haut.

Voici un squelette que vous pouvez copier tel quel :

# Suivi — Prénom NOM

- **Date d'arrivée :** AAAA-MM-JJ

## Valeurs et préférences

- **Ce qui compte le plus (top 3) :**
  1. …
  2. …
  3. …
- **Sujets préférés :** …
- **Sujets moins aimés :** …

## Brag document

| Titre | Date       | Description |
| ----- | ---------- | ----------- |
| …     | AAAA-MM-JJ | …           |

## Apprentissage supervisé

<!-- États : demandé · rejeté · en cours · terminé · partagé -->
<!-- Règle : jamais plus de 2 sujets « en cours » en même temps -->

| Sujet | État | Départ     | Durée est. | Description | Avancement |
| ----- | ---- | ---------- | ---------- | ----------- | ---------- |
| …     | …    | AAAA-MM-JJ | …          | …           | … %        |

Ce hub, c'est en quelque sorte le résumé matériel de cet article. Et les
notes de chaque 1:1 deviennent des pages enfant de cette page : le suivi
dans la durée d'un côté, le fil des échanges de l'autre.

Ce que je ne détaille pas ici, c'est ce qu'on se dit réellement en 1:1 et ce
qu'on cherche à y adresser
: c'est un sujet à part entière.

Et la suite ?

Il reste d'autres aspects du 1:1 et du suivi que je n'ai pas abordés ici. Si
vous voulez que je précise un point ou que j'aborde un thème en particulier,
mes réseaux sont accessibles depuis ce blog : écrivez-moi, je serai ravi de
vous lire.

Ce thème des citations et principes reçus se poursuivra dans un prochain
article consacré à « Donner des objectifs et de la vision ». Comme
toujours, vous pouvez retrouver l'ensemble de la série via le tag
engineering-management.

Engineering manager : rôle et posture

Antoine Caron — Thu, 15 Oct 2026 17:02:49 +0000

Cet article a été publié initialement sur mon blog.

Avant de commencer, une précision : ce qui suit n'est ni une méthode ni une
vérité générale. C'est un retour d'expérience personnel, forcément subjectif,
sur ce que le rôle d'engineering manager m'a appris. Je n'ai aucune prétention
à la démonstration, juste l'envie de partager honnêtement ce qui m'a construit
dans ce rôle.

C'est le premier article d'une série où je vais explorer, à chaque fois avec
un focus différent, ce que ce métier m'a apporté. Plutôt que de vous exposer
mes propres principes, j'ai préféré faire autrement : partager les citations
et les principes que des personnes qui ont compté dans mon parcours
(collègues, mentors) m'ont transmis, et vous dire ce qu'ils m'apportent au
quotidien. Ce premier épisode porte sur le rôle et la posture d'engineering
manager.

Si ces articles ouvrent des voies à quelques personnes, alors j'en serai
déjà ravi.

Une référence avant les citations : "Engineering Management for the Rest of Us"

Avant d'entrer dans les citations qui ont individuellement marqué mon
parcours, je ne peux pas commencer cette série sans mentionner une
référence : le livre Engineering Management for the Rest of
Us de Sarah Drasner.

C'est une vraie recommandation, du contenu de grande qualité. En un format
relativement court, elle aborde énormément de sujets et formalise une
multitude de concepts et de conseils de façon très simple. Si vous ne devez
lire qu'un seul livre sur le sujet, c'est celui-là.

Merci Sarah pour cette dédicace, obtenue lors de la DotJS 2025 où nous étions
tous les deux speakers et avons pu échanger brièvement.

Je citerai quand même un conseil tiré du livre : demander explicitement les
attentes qu'ont vos managés de vous.

C'est un exercice très sain, et vous verrez que chaque individu a des
besoins et des attentes très différentes. C'est là aussi que ressort une
nécessité importante : il vous faudra vous adapter à chaque individu de
l'équipe. Une méthode unique ne fonctionnera pas avec tout le monde, sinon
ce serait de la magie.

Le rôle du manager vs. celui de l'IC : hands on, hands off

"Tout ce que tu fais, l'équipe doit savoir et pouvoir le faire, mis à part
les aspects de management." (Florent Dubost)

Tous mes modèles en management d'équipe d'ingénierie ont toujours gardé un
aspect technique dans leur travail. Le pourcentage varie d'une personne à
l'autre, mais iels ont toujours eu les mains dedans.

Pour moi, engineering manager est un rôle étendu du rôle de contributeur
individuel — l'IC¹ —, pas un rôle qui s'y substitue.

C'est aussi ce que j'en interprète : se réserver des tâches et des sujets en
tant que "chef" est une mauvaise pratique. Si on veut pouvoir compter sur son
équipe, toute l'équipe doit pouvoir nous épauler.

Comment fonctionnerait l'équipe en cas de vacances si vous silotez des étapes
de développement, de planification, ou des tâches spécifiques ?

La posture face à l'équipe : confiance et délégation

"Ta priorité c'est ton équipe, puis les individus qui composent ton
équipe, et enfin les projets que ton équipe doit réaliser."
(Kenny Dits, mon chef
pendant de nombreuses années chez M6)

J'ai eu la chance d'avoir des managers humanistes. Je pense qu'il est
nécessaire de prioriser l'équipe pour construire de la confiance, et qu'avec
cette confiance, il n'y a plus de crainte à avoir pour l'accomplissement des
objectifs.

Pour la priorisation, il faut comprendre quelque chose qui n'apparaît pas
forcément à la première lecture. Cela signifie que vous devrez parfois
abandonner des projets ou des objectifs pour protéger les individus ou votre
équipe. Cela signifie également qu'il sera parfois nécessaire de sortir
quelqu'un de l'équipe, pour le bien de l'équipe. Ce sera votre
responsabilité, autant s'y préparer. On ne sacrifie pas une équipe pour un
individu ou un projet.

De plus, votre équipe saura répondre présente lors d'un besoin plus
important, car elle sait que si vous la sollicitez, c'est vraiment pour un
sujet qui compte.

La priorité descend de la base vers le sommet : d'abord l'équipe, puis les individus qui la composent, enfin les projets.

Oui, c'est une référence troll à la pyramide des tests, un modèle que tout le
monde connaît, que tout le monde cite, et que tout le monde finit par
retoucher à sa sauce tant il ne veut plus dire grand-chose. J'en ai
justement parlé dans une conférence avec Jules Poissonnet, mon ancien
alternant : Tester c'est tricher !.

La posture de challenge : débloquer et faire grandir

"Qu'est-ce qui t'en empêche ?" (Yann Verry, mon
ancien collègue, qui me l'a dit plusieurs fois)

Un manager, c'est aussi quelqu'un qui challenge et qui permet à son équipe
de sortir de ses blocages. C'est aussi être là pour débloquer des
situations, mentorer, accompagner dans des décisions.

Un manager est également là pour faire en sorte que les individus qui
composent son équipe puissent s'épanouir et progresser.

Ce que "servir" son équipe veut dire concrètement

"Je fonctionne comme ça, je fais confiance de base et après si besoin je
discute avec toi si il y a des choses à revoir."
(Étienne de Thoury,
mon actuel Head of chez Scaleway)

L'idée est simple : éviter le micromanagement, laisser de la liberté.

Quand on devient manager, on peut parfois ressentir du stress et se
retrouver à vouloir tout suivre, tout gérer.

C'est aussi souvent nos propres managers qui nous poussent, sans le
vouloir, vers ce travers : quand un n+1 demande un reporting ultra précis,
il ne reste pas beaucoup d'autre choix que de commencer à tout suivre. Je le
vois autrement : l'information en elle-même n'est pas un pouvoir. Savoir
vers qui la renvoyer l'est bien plus, car elle sera toujours plus pertinente
venant de la personne qui la maîtrise réellement.

J'en ai une autre lecture, qui me parle tout autant : ce stress est souvent
moins une question de contrôle que de confiance en soi. Si je vous confie
une tâche alors que moi-même je ne suis pas certain à 100 % du résultat, que
je n'ai pas confiance en moi pour la mener à bien, il me sera impossible de
vous faire confiance pour la réaliser. Et cette incertitude finit par
retomber sur le dos de la personne, ou de l'équipe.

L'effet miroir

"Quand tu réagis ou tu parles mal d'un projet ou d'une équipe en tant que
manager, tu peux être sûr que ton équipe réagira en ×10 dans quelques
semaines." (Florent Dubost)

Qu'on le veuille ou non, un manager est un modèle. Son équipe observe ses
réactions, son ton, la façon dont il parle d'un projet, d'une autre équipe,
d'une décision. Ce qui est capté, consciemment ou non, c'est ça qui se
répète et s'amplifie dans l'équipe au fil des semaines.

Si je me montre négatif ou désabusé sur un sujet, cette attitude ne reste pas
la mienne. Elle infuse les conversations de l'équipe, puis sa manière
d'aborder ce sujet avec les autres, et elle finit par me revenir, amplifiée.
L'inverse est vrai aussi : la confiance et l'énergie qu'on montre se
propagent de la même façon.

Ça veut dire faire attention non seulement à ce que je dis, mais à comment
je le dis, car c'est ça qui devient la norme de l'équipe, bien plus que
n'importe quelle consigne explicite.

La sécurité psychologique : une responsabilité de leader

"Chaque leader de chaque groupe d'influence est responsable de la sécurité
psychologique de son groupe d'influence." (Léa Coston, dans son talk
Les gens ne savent pas ce qu'ils font, la plupart du
temps !)

En tant qu'engineering manager, on est le leader du groupe d'influence que
constitue son équipe. La sécurité psychologique n'est pas un supplément
d'âme ou une option "sympa à avoir" : c'est une responsabilité structurelle
du rôle.

Ce n'est d'ailleurs pas qu'une conviction personnelle : le projet
Aristote
mené par Google, qui a étudié des centaines d'équipes internes, a montré que
le facteur le plus déterminant de la performance d'une équipe n'était ni les
compétences individuelles ni l'ancienneté, mais bien son niveau de sécurité
psychologique.

Une équipe en sécurité psychologique, c'est une équipe qui ose dire qu'elle
s'est trompée, qui ose remonter un problème avant qu'il ne devienne
critique, qui ose ne pas être d'accord avec vous. Une équipe qui n'a pas
cette sécurité apprend vite à se taire, et vous perdez l'information la plus
précieuse : celle qui arrive tôt.

Il y a là un vrai enjeu d'exemplarité : être capable de dire à son équipe
qu'on peut se tromper, qu'on s'est trompé, ou qu'on ne sait pas, ça rassure
chacun sur sa propre capacité à faire ou dire la même chose.

Ça rejoint directement l'effet miroir vu plus haut : la sécurité
psychologique ne se décrète pas, elle se construit par la façon dont vous
réagissez, en particulier quand quelque chose se passe mal.

Le bâton de pouvoir

"Le bâton de pouvoir" (une phrase lue quelque part, dont la source
m'échappe malheureusement)

Photo : collection du musée du Louvre.

Lorsqu'on décide de vous nommer responsable d'une équipe, cela signifie
qu'on a confiance en vous pour vous donner ce pouvoir de décision. Ce
pouvoir est un acte de confiance important, mais c'est aussi un fardeau : il
faut, dans la mesure du possible, éviter de trop l'utiliser au sein de votre
équipe.

Les décisions doivent rester collectives, mais il vous faudra parfois
arbitrer, plusieurs fois. C'est ce qu'on attend de vous, et non d'escalader
la décision plus haut si son scope ne concerne que votre équipe.

Une décision collective embarquera toujours bien plus l'équipe qu'une
décision descendante. Faire émerger le maximum d'intelligence collective
est, à mes yeux, l'une des missions les plus importantes d'un manager.

Se créer un réseau de managers

Un dernier point, essentiel selon moi : se créer un réseau de managers, dans
son entreprise ou ailleurs, avec qui échanger sur ces sujets, prendre des
avis, des conseils. Je vous assure que ça aide, énormément.

Une pensée pour les managers avec qui j'échange régulièrement : ils se
reconnaîtront, merci à eux.

Si vous n'en avez pas encore, des communautés en ligne existent, comme le
Slack Engineering Managers Community.

Et la suite ?

C'est le premier article de cette série sur mon retour d'expérience en tant
qu'engineering manager. Le prochain épisode abordera le 1:1 et le suivi
individuel. Vous pouvez retrouver tous les articles de la série via le tag
engineering-management.

Notes

IC, pour individual contributor (contributeur individuel) : un membre de l'équipe qui contribue directement à la production — code, design, etc. — sans responsabilité de management.

Managing Terraform Modules with Nx Monorepo

Antoine Caron — Sun, 02 Nov 2025 20:04:37 +0000

Introduction

Managing infrastructure as code at scale is challenging. When your organization grows beyond a handful of Terraform modules, you quickly encounter familiar problems: code duplication, inconsistent testing practices, unclear dependencies between modules, and the eternal question of whether to use a monorepo or split everything into separate repositories.

If you've worked with Terraform in a team environment, you've probably faced these pain points:

Running terraform fmt and terraform validate across dozens of modules manually
Uncertainty about which modules are affected by a change
Difficulty enforcing consistent standards across all modules
Time wasted running tests on unaffected modules in CI/CD
The challenge of managing dependencies between related modules

What if you could leverage the same powerful tooling that frontend teams use to manage their monorepos? Enter Nx - a smart build system that can transform how you manage Terraform modules.

Want to see this in action? I've created a complete demo repository showcasing all the concepts covered in this article, with seven Scaleway Terraform modules fully configured with Nx.

The Challenge of Managing Terraform Modules at Scale

The Multi-Repo Dilemma

Many organizations start with separate Git repositories for each Terraform module. This approach seems clean at first - each module has its own versioning, CI/CD pipeline, and release cycle. However, as your infrastructure grows, this strategy reveals its weaknesses:

Versioning Hell: When Module A depends on Module B, you need to carefully manage version pinning. Update Module B? Now you need to update Module A's version constraint, test it, and release a new version.
Cross-Module Changes: A breaking change that affects multiple modules requires coordinating PRs across multiple repositories, each with its own review and merge timeline.
Inconsistent Tooling: Each repository might have different CI configurations, different testing approaches, or even different versions of tools like tflint or terraform-docs.

The Monorepo Challenges

Moving to a monorepo solves some problems but creates others:

Build Times: Without smart tooling, CI runs tests on ALL modules even when you only changed one.
Dependency Tracking: How do you know which modules depend on each other? Manual documentation? Good luck keeping that up to date.
Task Orchestration: Running terraform fmt across 50 modules means writing bash scripts that find all the directories, loop through them, and aggregate results.
Developer Experience: Developers need clear visibility into what's affected by their changes and confidence that they're running the right tests.

The traditional approach to Terraform module management leaves teams choosing between the coordination overhead of multi-repo or the inefficiency of a naive monorepo.

Why Nx for Terraform Modules?

Nx is a smart build system originally designed for JavaScript/TypeScript monorepos, but it's fundamentally language-agnostic. At its core, Nx provides exactly what we need for managing Terraform modules:

1. Intelligent Task Orchestration

Nx understands your project graph - which modules depend on which. When you run a task, Nx:

Only executes tasks on affected projects based on your git diff
Runs tasks in the correct order based on dependencies
Executes independent tasks in parallel to maximize speed

For Terraform, this means running terraform validate only on the modules that changed, and their dependents - not the entire monorepo.

2. Dependency Graph Visualization

Run nx graph and see a visual representation of how your modules relate to each other. This is invaluable for understanding impact and planning refactors.

3. Code Generation

Nx generators let you scaffold new modules with consistent structure. Want a new Terraform module with the right directory structure, a project.json, tests, and documentation? One command.

4. Consistent Tooling Across Projects

Define tasks once, inherit them across all modules. Every module gets fmt, validate, lint, and test targets without copying configuration files everywhere.

The beauty of Nx is that it doesn't change how you write Terraform - it enhances how you manage Terraform modules at scale.

Setting Up an Nx Workspace for Terraform

Let's build a practical Nx workspace for managing Terraform modules. I'll walk you through the setup step by step.

Creating the Workspace

First, create a new Nx workspace:

npx create-nx-workspace@latest terraform-modules --preset=npm
cd terraform-modules

Choose the "npm" preset - we're not building a JavaScript application, we just want Nx's task orchestration capabilities.

Workspace Structure

Here's a recommended structure for organizing Terraform modules:

terraform-modules/
├── nx.json
├── package.json
├── modules/
│   ├── scw-vpc/
│   │   ├── project.json
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   ├── scw-k8s/
│   │   ├── project.json
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   └── scw-database/
│       ├── project.json
│       └── ...
└── tools/
    └── scripts/

Each Terraform module lives in modules/ and has its own project.json file where we define Nx tasks.

Configuring Nx for Terraform Projects

The project.json file is where Nx magic happens. Here's an example for the scw-vpc module:

{
  "name": "scw-vpc",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "projectType": "library",
  "sourceRoot": "modules/scw-vpc",
  "targets": {
    "fmt": {
      "executor": "nx:run-commands",
      "options": {
        "command": "terraform fmt -check",
        "cwd": "modules/scw-vpc"
      }
    },
    "fmt-fix": {
      "executor": "nx:run-commands",
      "options": {
        "command": "terraform fmt",
        "cwd": "modules/scw-vpc"
      }
    },
    "validate": {
      "executor": "nx:run-commands",
      "options": {
        "commands": ["terraform init -backend=false", "terraform validate"],
        "cwd": "modules/scw-vpc",
        "parallel": false
      }
    },
    "lint": {
      "executor": "nx:run-commands",
      "options": {
        "command": "tflint",
        "cwd": "modules/scw-vpc"
      }
    },
    "docs": {
      "executor": "nx:run-commands",
      "options": {
        "command": "terraform-docs markdown . > README.md",
        "cwd": "modules/scw-vpc"
      }
    }
  },
  "tags": ["type:terraform", "cloud:scaleway", "layer:network"]
}

The nx:run-commands executor lets us run any shell command - perfect for Terraform CLI commands.

Now you can run:

nx fmt scw-vpc          # Check formatting
nx validate scw-vpc     # Validate configuration
nx lint scw-vpc         # Run tflint
nx run-many -t validate # Run validate on all modules

Managing Dependencies Between Terraform Modules

One of Nx's most powerful features is its understanding of dependencies. But Terraform modules don't use import statements like JavaScript - so how does Nx know about dependencies?

Implicit Dependencies

Nx can infer dependencies by analyzing your Terraform code. When scw-k8s module references the scw-vpc module with a relative path:

module "vpc" {
  source = "../scw-vpc"
  # ...
}

Nx can detect this relationship. Configure implicit dependencies in your root nx.json:

{
  "pluginsConfig": {
    "@nx/dependency-checks": {
      "checkVersionMismatch": false
    }
  },
  "targetDefaults": {
    "validate": {
      "dependsOn": ["^validate"]
    }
  }
}

Explicit Dependencies

For more control, explicitly declare dependencies in your project.json:

{
  "name": "scw-k8s",
  "implicitDependencies": ["scw-vpc"],
  "targets": {
    // ...
  }
}

This tells Nx that scw-k8s depends on scw-vpc. Now when you run:

nx validate scw-k8s

Nx will first validate scw-vpc, then scw-k8s. And more importantly:

nx affected -t validate

If you change scw-vpc, Nx knows that scw-k8s is affected and will run validation on both modules.

Visualizing the Graph

See your entire module ecosystem:

nx graph

This opens an interactive browser view showing all your modules and their relationships. It's incredibly useful for:

Onboarding new team members
Planning large refactors
Understanding blast radius of changes
Identifying circular dependencies

Building a Task Pipeline

Nx really shines when you build task pipelines that automatically run in the correct order. Let's create a comprehensive set of targets for our Terraform modules.

Defining Target Dependencies

In your nx.json, use targetDefaults to create a pipeline:

{
  "targetDefaults": {
    "fmt": {
      "dependsOn": []
    },
    "validate": {
      "dependsOn": ["^validate", "fmt"]
    },
    "lint": {
      "dependsOn": ["validate"]
    },
    "security": {
      "dependsOn": ["lint"]
    }
  }
}

The ^ prefix means "dependencies of dependencies". When you run nx security scw-k8s:

Nx validates all modules that scw-k8s depends on
Then formats scw-k8s
Then validates scw-k8s
Then lints scw-k8s
Finally runs security scans on scw-k8s

All automatically, in parallel where possible.

Common Targets

Here's a complete project.json with all the targets you'll typically need:

{
  "name": "scw-vpc",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "projectType": "library",
  "sourceRoot": "modules/scw-vpc",
  "targets": {
    "fmt": {
      "executor": "nx:run-commands",
      "options": {
        "command": "terraform fmt -check",
        "cwd": "modules/scw-vpc"
      }
    },
    "fmt-fix": {
      "executor": "nx:run-commands",
      "options": {
        "command": "terraform fmt",
        "cwd": "modules/scw-vpc"
      }
    },
    "validate": {
      "executor": "nx:run-commands",
      "options": {
        "commands": ["terraform init -backend=false", "terraform validate"],
        "cwd": "modules/scw-vpc",
        "parallel": false
      }
    },
    "lint": {
      "executor": "nx:run-commands",
      "options": {
        "commands": ["tflint --init", "tflint"],
        "cwd": "modules/scw-vpc",
        "parallel": false
      }
    },
    "security": {
      "executor": "nx:run-commands",
      "options": {
        "command": "checkov -d .",
        "cwd": "modules/scw-vpc"
      }
    },
    "docs": {
      "executor": "nx:run-commands",
      "options": {
        "command": "terraform-docs markdown . > README.md",
        "cwd": "modules/scw-vpc"
      }
    }
  },
  "tags": ["type:terraform", "cloud:scaleway", "layer:network"]
}

Running Tasks Across Multiple Projects

# Run fmt on all modules
nx run-many -t fmt

# Run affected validations based on git changes
nx affected -t validate,lint

# Run tasks in specific order
nx run-many -t fmt,validate,lint,security

# Run on modules with specific tags
nx run-many -t validate --projects=tag:cloud:scaleway

Code Generation and Scaffolding

Manually creating project.json files for each new module gets tedious. Nx generators solve this by scaffolding consistent module structures with a single command.

Creating a Custom Generator

Create a generator in tools/generators/terraform-module/:

// tools/generators/terraform-module/index.js
const { formatFiles, generateFiles, Tree } = require("@nx/devkit");
const path = require("path");

async function terraformModuleGenerator(tree, schema) {
  const { name, cloud, layer } = schema;
  const projectRoot = `modules/${name}`;

  // Generate files from templates
  generateFiles(tree, path.join(__dirname, "files"), projectRoot, {
    name,
    cloud,
    layer,
    tmpl: "",
  });

  // Update workspace
  const projectConfiguration = {
    name,
    projectType: "library",
    sourceRoot: projectRoot,
    targets: {
      fmt: {
        /* ... */
      },
      validate: {
        /* ... */
      },
      lint: {
        /* ... */
      },
      test: {
        /* ... */
      },
    },
    tags: [`type:terraform`, `cloud:${cloud}`, `layer:${layer}`],
  };

  addProjectConfiguration(tree, name, projectConfiguration);
  await formatFiles(tree);
}

module.exports = terraformModuleGenerator;
module.exports.schema = {
  properties: {
    name: { type: "string" },
    cloud: { type: "string", enum: ["scaleway", "aws", "gcp", "azure"] },
    layer: {
      type: "string",
      enum: ["network", "compute", "storage", "security"],
    },
  },
  required: ["name", "cloud", "layer"],
};

Template Files

Create templates in tools/generators/terraform-module/files/:

# tools/generators/terraform-module/files/main.tf__tmpl__
terraform {
  required_version = ">= 1.0"

  required_providers {
    <%= cloud %> = {
      source  = "hashicorp/<%= cloud %>"
      version = "~> 5.0"
    }
  }
}

# Add your resources here

# tools/generators/terraform-module/files/variables.tf__tmpl__
variable "name" {
  description = "Name of the <%= name %> module"
  type        = string
}

# tools/generators/terraform-module/files/outputs.tf__tmpl__
output "id" {
  description = "ID of the created resource"
  value       = ""
}

Using the Generator

Now create new modules consistently:

nx g @nx/workspace:workspace-generator terraform-module \
  --name=scw-function \
  --cloud=scaleway \
  --layer=compute

# Creates:
# modules/scw-function/
# ├── project.json
# ├── main.tf
# ├── variables.tf
# ├── outputs.tf
# └── README.md

Every new module gets the same structure, targets, and tags. No copy-pasting required.

Testing Strategies

Testing infrastructure code is critical but often overlooked. With Nx, you can build a comprehensive testing pipeline that runs efficiently across all your modules.

Level 1: Static Analysis

terraform fmt & validate
Basic syntax and semantic validation:

nx run-many -t fmt,validate

tflint
Catch common mistakes and enforce best practices:

{
  "lint": {
    "executor": "nx:run-commands",
    "options": {
      "commands": ["tflint --init", "tflint --format compact"],
      "cwd": "modules/scw-vpc",
      "parallel": false
    }
  }
}

checkov
Security and compliance scanning:

nx run-many -t security  # Runs checkov on all modules

Orchestrating Static Analysis with Nx

The magic happens when you combine Nx's dependency graph with your validation pipeline:

# Only validate modules affected by your changes
nx affected -t validate,lint --base=main

# Validate a module and all its dependencies
nx validate scw-k8s --with-deps

# Run security scans in parallel (independent modules)
nx run-many -t security --parallel=3

# Run full quality checks on affected modules
nx affected -t fmt,validate,lint,security --base=main

This can reduce CI time from hours to minutes for large infrastructure repos.

CI/CD Integration

The real power of Nx shows up in CI/CD. Instead of running all checks on all modules, you only run what's needed.

GitHub Actions Example

# .github/workflows/ci.yml
name: CI

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  affected:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0 # Important for nx affected

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18"

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: 1.6.0

      - name: Install dependencies
        run: npm ci

      - name: Install tflint
        run: |
          curl -s https://raw.githubusercontent.com/terraform-linters/tflint/master/install_linux.sh | bash

      - name: Derive SHAs for affected command
        uses: nrwl/nx-set-shas@v3

      - name: Run affected format check
        run: npx nx affected -t fmt --base=$NX_BASE --head=$NX_HEAD

      - name: Run affected validate
        run: npx nx affected -t validate --base=$NX_BASE --head=$NX_HEAD

      - name: Run affected lint
        run: npx nx affected -t lint --base=$NX_BASE --head=$NX_HEAD --parallel=3

      - name: Run affected security scans
        run: npx nx affected -t security --base=$NX_BASE --head=$NX_HEAD

What This Does

Only checks affected modules: If you change scw-vpc, only scw-vpc and modules that depend on it run checks
Parallel execution: Independent modules run in parallel (configured with --parallel=3)
Fast feedback: Most PRs only touch 1-2 modules, so CI completes in seconds instead of minutes

GitLab CI Example

# .gitlab-ci.yml
stages:
  - validate
  - security

.nx-affected:
  image: node:18
  before_script:
    - npm ci
    - curl -s https://raw.githubusercontent.com/terraform-linters/tflint/master/install_linux.sh | bash
  variables:
    NX_BASE: $CI_MERGE_REQUEST_DIFF_BASE_SHA
    NX_HEAD: $CI_COMMIT_SHA

affected:validate:
  extends: .nx-affected
  stage: validate
  script:
    - npx nx affected -t validate,lint --base=$NX_BASE --head=$NX_HEAD --parallel=3

affected:security:
  extends: .nx-affected
  stage: security
  script:
    - npx nx affected -t security --base=$NX_BASE --head=$NX_HEAD
  only:
    - merge_requests

Results

In a real-world scenario with 30+ Terraform modules:

Before Nx: Every PR ran checks on all 30 modules (~15 min)
After Nx: Most PRs only check 1-3 affected modules (~2 min)
Savings: 87% reduction in CI time

Managing Releases with Nx

One of the most powerful yet underrated features of Nx is its ability to manage releases in a monorepo. For Terraform modules, proper release management is crucial for versioning, changelog generation, and coordinating changes across dependent modules.

Using Nx Release

Nx provides a built-in release system that handles versioning, changelog generation, and git tagging automatically.

Initial Setup

First, configure Nx Release in your nx.json:

{
  "release": {
    "projects": ["modules/*"],
    "projectsRelationship": "independent",
    "version": {
      "generatorOptions": {
        "packageRoot": "{projectRoot}",
        "currentVersionResolver": "git-tag"
      }
    },
    "changelog": {
      "projectChangelogs": {
        "createRelease": "github",
        "file": "{projectRoot}/CHANGELOG.md",
        "renderOptions": {
          "authors": true,
          "commitReferences": true
        }
      }
    },
    "git": {
      "commit": true,
      "tag": true,
      "commitMessage": "chore(release): publish {projectName} {version}"
    }
  }
}

Creating a Release

When you're ready to release modules that have changed:

# See which modules have changed since last release
nx release --dry-run

# Release only affected modules with automatic version bump
nx release --projects=tag:cloud:scaleway

# Release a specific module with a specific version
nx release scw-vpc --specifier=1.2.0

Automated Semantic Versioning

Nx can automatically determine version bumps based on conventional commits:

# Patch version (fix: commits)
git commit -m "fix(scw-vpc): correct subnet CIDR calculation"

# Minor version (feat: commits)
git commit -m "feat(scw-k8s): add autoscaling support"

# Major version (BREAKING CHANGE: in commit body)
git commit -m "feat(scw-vpc)!: redesign network architecture

BREAKING CHANGE: VPC module now requires new subnet configuration"

# Run release
nx release --projects=tag:cloud:scaleway --dry-run
# Nx will suggest: scw-vpc: 1.2.3 → 2.0.0, scw-k8s: 1.5.0 → 1.6.0

Changelog Generation

Nx automatically generates changelogs for each module:

# modules/scw-vpc/CHANGELOG.md

## 2.0.0 (2025-11-01)

### ⚠ BREAKING CHANGES

- **scw-vpc:** VPC module now requires new subnet configuration

### Features

- **scw-vpc:** redesign network architecture ([a1b2c3d](https://github.com/org/repo/commit/a1b2c3d))

### Authors

- Antoine Caron (@Slashgear)

Release Workflow in CI

Automate releases with GitHub Actions:

# .github/workflows/release.yml
name: Release

on:
  push:
    branches: [main]

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18"

      - name: Install dependencies
        run: npm ci

      - name: Configure Git
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"

      - name: Release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          npx nx release --skip-publish

Tagging Strategy

Nx creates git tags for each module release:

# Tags created by Nx
scw-vpc@2.0.0
scw-k8s@1.6.0
scw-database@1.3.1

External consumers can reference specific versions:

# Using git tags to reference specific module versions
module "vpc" {
  source = "git::https://github.com/org/terraform-modules.git//modules/scw-vpc?ref=scw-vpc@2.0.0"
}

Independent vs Fixed Versioning

Nx supports two release strategies:

Independent (recommended for Terraform modules):

Each module has its own version
Modules only bump when they change
"projectsRelationship": "independent"

Fixed (useful for tightly coupled modules):

All modules share the same version
All versions bump together even if unchanged
"projectsRelationship": "fixed"

Benefits

Automatic versioning: Based on conventional commits
Generated changelogs: No manual CHANGELOG.md updates
Git tagging: Automatic and consistent
Affected awareness: Only release modules that changed
GitHub releases: Automatic release creation with notes

This makes managing dozens of Terraform modules significantly less painful than manual versioning and tagging.

Real-World Use Case

Let's walk through a concrete example: a SaaS company managing their Scaleway infrastructure with Nx. This example is based on the nx-terraform-demo repository, which you can clone and explore yourself.

The Setup

They have the following modules:

scw-vpc - Private network configuration
scw-k8s - Kubernetes Kapsule cluster (depends on vpc)
scw-database - Managed PostgreSQL (depends on vpc)
scw-object-storage - S3-compatible object storage (independent)
scw-registry - Container registry (depends on vpc)
scw-loadbalancer - Load balancer (depends on vpc, k8s)
scw-monitoring - Observability stack (depends on k8s)

The Dependency Graph

scw-vpc
  ├── scw-k8s
  │   ├── scw-loadbalancer
  │   └── scw-monitoring
  ├── scw-database
  └── scw-registry

scw-object-storage (independent)

Run nx graph to visualize this automatically.

Scenario: Updating the VPC Module

A developer needs to add a new subnet to scw-vpc. Here's what happens:

# Developer makes changes to scw-vpc
git checkout -b feat/add-subnet
# ... edit scw-vpc/main.tf ...

# Check what's affected
nx show projects --affected
# Output: scw-vpc, scw-k8s, scw-database, scw-registry, scw-loadbalancer, scw-monitoring

# Run validation only on affected modules
nx affected -t validate,lint
# Validates: vpc → k8s, database, registry → loadbalancer, monitoring

# Push and CI runs affected checks
# Only the 6 affected modules are validated, not all 7

Result: Instead of running checks on all modules, only the affected ones run. The independent module (scw-object-storage) is skipped entirely.

Scenario: Adding New Feature to Monitoring

# Developer updates scw-monitoring
nx show projects --affected
# Output: scw-monitoring (only!)

# CI only validates this one module
nx affected -t validate,lint,security --base=main

Result: All other 6 modules skipped, massive time savings.

The Impact

Before Nx:

Every PR: validate all 7 modules, run all checks (~20 min)
Developers waited, context-switched, lost productivity

After Nx:

Small changes: 1-2 modules affected (~3 min)
VPC changes: 6 modules affected (~8 min)
Clear visibility with nx graph on what breaks

Best Practices

After implementing Nx with Terraform modules across multiple teams, here are the lessons learned:

1. Use Meaningful Tags

Tags enable powerful filtering. Be strategic:

{
  "tags": [
    "type:terraform", // All terraform projects
    "cloud:scaleway", // Cloud provider
    "layer:network", // Infrastructure layer
    "team:platform", // Owning team
    "env:multi" // Supports multiple envs
  ]
}

Then run targeted commands:

nx run-many -t validate --projects=tag:team:platform
nx run-many -t security --projects=tag:cloud:scaleway

2. Keep Modules Small and Focused

Each module should do one thing well:

✅ Good: scw-vpc, scw-k8s, scw-database
❌ Bad: scw-full-infrastructure

Small modules = better reusability and easier testing.

3. Use Target Dependencies Wisely

Define a clear pipeline in nx.json:

{
  "targetDefaults": {
    "validate": {
      "dependsOn": ["^validate", "fmt"]
    },
    "test": {
      "dependsOn": ["^test", "validate", "lint"]
    }
  }
}

This ensures tasks run in the right order automatically.

4. Document with terraform-docs

Automate documentation generation:

{
  "docs": {
    "executor": "nx:run-commands",
    "options": {
      "command": "terraform-docs markdown table --output-file README.md .",
      "cwd": "modules/scw-vpc"
    }
  }
}

Run nx run-many -t docs to update all module docs at once.

5. Implement Pre-commit Hooks

Use Husky to run quick checks before commits:

npx husky install
npx husky add .husky/pre-commit "npx nx affected -t fmt-fix,validate"

Limitations and Considerations

Nx is powerful, but it's not a silver bullet. Here are honest tradeoffs to consider:

Learning Curve

Your team needs to learn:

Nx concepts (projects, targets, affected commands)
Node.js/npm basics (even though you're not writing JavaScript)
How to write project.json files

Mitigation: Start with 3-5 modules, prove the value, then expand.

Node.js Dependency

You now need Node.js in your infrastructure workflows. Some teams find this odd.

Counter-argument: Node.js is ubiquitous, lightweight, and your CI already has it. The benefits far outweigh this concern.

State Management Unchanged

Nx doesn't help with:

Terraform state files
State locking
Remote backends
Workspace management

You still need proper Terraform state hygiene. Nx is purely about workspace organization and task orchestration.

Not Ideal for Small Projects

If you have 1-3 Terraform modules that rarely change, Nx is overkill. The overhead isn't worth it.

Use Nx when:

5+ modules
Frequent changes
Multiple team members
Complex dependencies

Module Source References

Modules in the monorepo use relative paths:

source = "../scw-vpc"

External consumers need a different approach:

Publish to a module registry
Use git tags with specific refs
Or keep internal modules internal

When NOT to Use This Approach

Single module projects: Just use plain Terraform
Completely independent modules: If modules never interact, separate repos might be simpler
Team resistant to change: Cultural fit matters more than technical benefits

Be pragmatic. Nx solves specific problems - make sure you have those problems first.

Conclusion

Managing Terraform modules at scale doesn't have to be painful. Nx brings proven monorepo practices from the frontend world to infrastructure code, offering:

Intelligent task orchestration - Run only what's affected
Dependency awareness - Understand module relationships automatically
Faster CI/CD - 80%+ time savings in real-world scenarios
Better DX - Consistent tooling, code generation, and clear workflows

The initial setup requires investment - learning Nx concepts, creating project.json files, updating CI workflows. But for teams managing 5+ Terraform modules with frequent changes, the ROI is substantial.

Start small: pick 3-5 modules, prove the concept, measure the impact. If it works for you (and it likely will), expand to your full infrastructure codebase.

The future of infrastructure management is smart, graph-aware tooling. Nx brings us closer to that future today.

Resources

Demo Repository

nx-terraform-demo - Complete working example with 7 Scaleway Terraform modules managed with Nx

Nx Documentation

Terraform Tooling

terraform-docs - Automated documentation generation
tflint - Terraform linter
checkov - Security and compliance scanning

Scaleway Provider

Further Reading

Monorepo Tools - Comparison of monorepo solutions
Terraform Best Practices

Have you tried managing Terraform with Nx? I'd love to hear about your experience. Find me on Bluesky or GitHub!

How to automatically merge dependabot pull requests with Github Actions ?

Antoine Caron — Tue, 10 May 2022 00:00:00 +0000

Recently, I’ve been working a lot on industrializing this blog (maybe even a little too much). This blog is my playground, I experiment, I play, I test things. I admit that it’s over-engineered but I’m having a lot of fun with it. 😅

Since its release, I tried to use dependabot from github on my repositories. At the beginning without much conviction. As much as I thought it was great in principle, the noise generated by the dozens of open PRs per day was really annoying. As a maintainer of various open-source projects, I have been victim of dependabot PR flood several times. A real nightmare.

I had foolishly made no effort to configure it. Recently, I thought I should give it another chance. So I set up this configuration that allowed me to update my JS dependencies and used github actions in my workflows.

version: 2
updates:
  - package-ecosystem: 'npm' # See documentation for possible values
    directory: '/' # Location of package manifests
    open-pull-requests-limit: 25
    schedule:
      interval: 'daily'
  - package-ecosystem: 'github-actions' # See documentation for possible values
    directory: '/' # Location of package manifests
    open-pull-requests-limit: 25
    schedule:
      interval: 'daily'

No lie, with this configuration, on this blog developed with Gatsby, Dependabot was opening up to 20 Pull Requests per week.

⚠️ Limits

At the beginning, when you see all the PRs opening with all the dependencies updates, you are quite happy. However, managing this every week is really time consuming. Moreover, when we merge these PRs in a chain, we generate in cascade conflicts on the package.json file which prevents the merge 😒. It is therefore often necessary to wait for dependabot to rebase the PR by itself, for the tests to pass and then wait for the Pull Request to merge.

♻️ Let’s merge it automatically!

Having set up E2E tests on this blog, the check ✅ given by my continuous integration workflow is very reassuring.You can have a look at this article which describes how I set up these tests

With this automation, I’m pretty serene when I merge the dependabot update PR. So I thought, “Why not automatically merge the PRs that pass the E2E tests?”

To do this, in my continuous integration workflow, I just had to add a new job configured this way.

 dependabot:
    name: 'Dependabot'
    needs: [build, e2e] # After the E2E and build jobs, if one of them fails, it won't merge the PR.
    runs-on: ubuntu-latest
    if: ${{ github.actor == 'dependabot[bot]' && github.event_name == 'pull_request'}} # Detect that the PR author is dependabot
    steps:
      - name: Enable auto-merge for Dependabot PRs
        run: gh pr merge --auto --merge "$PR_URL" # Use Github CLI to merge automatically the PR
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

If you want to see the real example, take a look at this blog workflow.

👮‍ In the end, is it really safer?

SWithout explaining what dependabot is, one could think that all this could bring more security. Indeed, as soon as security patches are available, they would be automatically applied and deployed on my blog without any manual manipulation being necessary.

My availability to merge the PRs of dependabot being limited, one could say that setting up automation improves things. A good E2E testing strategy ensuring that I don’t break anything too important on my site seems really convenient.

But in the end, who controls the updates and what they contain? Who makes sure that they don’t contain malicious code? This blog is not a sandbox for me, so it’s not very problematic. So think carefully before setting it up.

Best practices for Web application maintenance

Antoine Caron — Sun, 05 Sep 2021 00:00:00 +0000

How not to throw away your application every two years?

Feedback based on best practices applied to the web platform developed at Bedrock Streaming

A bit of context

At Bedrock Streaming many teams develop and maintain frontend applications for our customers and users. Some of those application are not very young. In fact, the application I’m mainly working on is a website whose developments started in 2014. I have already mentioned it in different articles of this blog.

You might think: “Oh poor people, maintaining an almost 10 year old application must be hell!”

Don’t worry, it’s not the case! I have worked on projects that are much less old but where the development of new features was much more painful.

Today the project is technically up to date, we must be on the latest version of React while it had started on a version 0.x.x. In this world of web technologies often criticized (eg: the many articles on the Javascript Fatigue) whose tools and practices are constantly evolving, keeping a project “up to date” remains a real challenge.

Moreover, in the context of this project, in almost 10 years, we have had about 100 contributors. Some have only stayed a few months/years. How can we keep the maximum knowledge on “How we do things and how it works?” in such a moving human context?

This is what I would like to present you.

With the help of my colleagues, I have collected the list of good practices that still allow us to maintain this project today. With Florent Dubost, we often thought that it would be interesting to publish it. We hope you will find it useful.

Set rules and automate them

A project that stands the test of time is first and foremost a set of knowledge that is stacked one on top of the other. It’s like the Kapla tower you used to build as a child, trying to get as high as possible. A solid base on which we hope to add as much as possible before a potential fall.

From the beginning of a project, we have to make important decisions about “How do we want to do things? We think for example about “What format for our files? How do we name this or that thing?” Writing accurate documentation of “How we do things” might seem like a good idea.

However, documentation is cool, but it tends to get outdated very quickly. Our decisions evolve, but documentation does not.

“Times change but not READMEs.”

Olivier Mansour (deputy CTO at Bedrock)

Automating the checking of each of the rules we impose on ourselves (on our codebase or our processes) is much more durable. To make it simple, we avoid as much as possible to say “We should do things like that”, and we prefer “we’ll code something that checks it for us”. On top of that, on the JS side we are really well equipped with tools like Eslint that allow us to implement our own rules.

So the reflex we try to adopt is the following:

“We should try to do it like this now!”
“Ok that’s interesting, but how can we make sure we do it like that automatically with our CI (Continuous Integration)?”

Continuous Integration of a project is the perfect solution to not miss anything on every Pull Request we provide. Reviews are only easier because you don’t have to worry about all the rules that are already automated. In this model, the review is more for knowledge sharing than for typo copying and other non-compliance with the project conventions.

In this principle, we must therefore try to banish oral rules. The time of the druids is over, if all the good practices of a project have to be transmitted orally, it will only take longer to guide new developers into your team.

A project is not set in stone. These rules evolve with time. It is therefore preferable to add rules that have a script that will autofix the whole codebase intelligently. Many Eslint rules offer this, and it is a very important selection criteria when choosing new conventions.

eslint --fix

A very strict rule that will force you to modify your code manually before each push is annoying in the long run and will annoy your teams. Whereas a rule (even a very strict one) that can auto-fix itself at commit time will not be seen as annoying.

How to decide to add new rules ?

This question may seem thorny, take for example the case of <tab> / <space> in files. For this, we try to avoid the endless debates and follow the trend and rules of the community. For example, our Eslint configuration base is based on Airbnb’s which seems to have some success in the JS community. But if the rule we want to impose on ourselves is not available in Eslint or other tools, we sometimes prefer not to follow the rule rather than say “We’ll do it without a checking CI”.

The almost exhaustive list 🤞

The file format is tracked managed by Editorconfig, prettier and Eslint. We have opensourced our own configuration, if it is of any use to you.
We use a specific commit name to generate our changelog. To make sure devs follow it, a simple step in our CI checks it.
We don’t want a dev to make our JS bundles very big in production, so we track and measure their size in the CI. We use an in-house tool but we can recommend the [BuildTracker] tool (https://buildtracker.dev/).
Test coverage is not an indicator for the team, not all lines have the same need for us to be tested. Some teams at Bedrock however follow this indicator which at least has the interest to give a trend.
Our unit tests obviously run on the CI, these must pass.
Our functional tests (End to end: E2E) run on Chrome Headless, they must be green.
The logs of our E2E tests are retrieved and parsed to avoid errors or React warnings (the parsing script is however complicated to maintain)
Functional tests run in a sandbox where the whole network is proxied. We make sure that our tests do not depend on a non mocked API that could slow down their execution.
During the E2E tests we check that no image request has generated a 404.
We perform some accessibility checks with Axe during our E2E tests.
We check some rules on the CSS with Stylelint and bemlinter (we don’t use BEM anymore but there is still some style managed in SCSS that we migrate little by little in StyledComponent)
The project is a monorepo on which we try to maintain the same dependencies versions for each package. For that we have developed a tool that allows to do this check monorepo-dependencies-check
We check that our yarn.lock file has not been inadvertently modified or that it has been updated with respect to the modifications of the package.json.
Terraform is used to manage our cloud resources, we check that the file format is correct.

Test, test, test

I hope that in 2021 it is no longer necessary to explain why automatic testing of your application is essential to make it sustainable. In JS, we are rather well equipped in terms of testing tools today. However, the eternal question remains:

“What do we want to test?”

Globally if we search on the internet this question, we see that different needs make emerge very different practices and testing tools. It would be very presumptuous to think that there is a good way to automatically test your application. This is why it is preferable to define one or more test strategies that meet defined and limited needs.

Our test strategies are based on two distinct goals:

To automate the verification of the functionalities proposed to the users by putting ourselves in their place.
To provide us with efficient solutions to specify the way we implement our technical solutions to allow us to make them evolve more easily.

To do this, we perform two “types of tests” that I propose to present here.

Our E2E tests

We call them “functional tests”, they are End-to-end (E2E) tests on a very efficient technical stack composed of CucumberJS, WebdriverIO with ChromeHeadlessThis is a technical stack set up at the beginning of the project (at the time with PhantomJS for the oldest among you)

This stack allows us to automate the piloting of tests that control a browser. This browser will perform actions that are as close as possible to what our real users can do while checking how the site reacts.

A few years ago, this technical stack was rather complicated to set up, but today it is rather simple to do.The site that hosts this blog post is itself proof of this. It only took me about ten minutes to set up this stack with the WebdriverIo CLI to verify that my blog is working as expected.

I recently published an article presenting the implementation of this stack.

So here is an example of an E2E test file to give you an idea:

Feature: Playground

  Background: Playground context
    Given I use "playground" test context

  Scenario: Check if playground is reachable
    When As user "toto@toto.fr" I visit the "playground" page
    And I click on "playground trigger"
    Then I should see a "visible playground"
    And I should see 4 "playground tab" in "playground"

    When I click on "playground trigger"
    Then I should not see a "visible playground"

    # ...

And it looks like this in local with my Chrome browser!

Here is a diagram that explains how this stack works:

Today, Bedrock’s web application has over 800 E2E test cases running on each of our Pull Request and the master branch. They assure us that we are not introducing any functional regression and that’s just great!

👍 The positives

WebdriverIO also allows us to run these same tests on real devices on a daily basis through the paid SAAS service Browserstack. So we have every day a job that makes sure that our site works correctly on a Chrome last version on Windows 10 and Safari on MacOs.
These tests allow us to easily document the functionality of the application using the Gherkin language.
They allow us to reproduce cases that are far from nominal. In a TDD logic, they allow us to advance on the development without having to click for hours.
These tests allowed us not to break the old version of the site which is still in production for some customers while our efforts are concentrated on the new one.
They give us real confidence.
Thanks to our library superagent-mock, we can fixturer (plug, mock) all the APIs we depend on and thus even check the error cases. Also, mocking the browser’s XHR layer allows for a significant improvement in test execution time. 🚀
They give us access to extended uses like:
- checking accessibility rules
- check the browser console logs (to avoid introducing errors or React Warning for example)
- monitoring all network calls of the site through a proxy
- and so on…

👎 The complications

Maintaining this stack is complicated and expensive. Since few resources are published on this domain, we sometimes find ourselves digging for days to fix them 😅. Sometimes we feel quite alone in having these worries.
It is very easy to code a so-called flaky E2E test (ie: a test that can fail randomly). They make us think that something is broken. They sometimes take us a long time to stabilize. It is still much better to remove a test that will not give you a stable result.
Running all the tests takes a lot of time on our continuous integration. We must regularly work on their optimization so that the feedback they provide you is as fast as possible. These important times also cost money, because we have to run these tests on machines. For your information, the infrastructure of the website (just the hosting of our Node servers + static files + CDN) cost much less than our continuous integration. This obviously makes our Ops team smile! 😊
The new recruits in our teams have often never done this kind of testing, so there is a ~~struggle~~ phase of learning…
Some features are sometimes too complicated to test with our E2E stack (for example, payment paths that depend on third parties). So we sometimes fall back on other techniques with Jest, especially with a less unitary scope.

Our “unit” tests

To complete our functional tests we also have a stack of tests written with Jest. We call these tests unit tests because we have as a principle to try to always test our JS modules independently from the others.

Let’s not debate here about “Are these real unit tests?”, there are enough articles on the internet about this topic.

We use these tests for different reasons that cover needs that our functional tests do not cover:

to help us develop our JS modules with TDD practices.
to document and describe how a JS module works.
test very/too complicated edge cases with our E2E tests.
facilitate the refactoring of our application by showing us the technical impacts of our modifications.

With these tests, we put ourselves at the level of a utility function, a Redux action, a reducer, a React component. We rely mainly on the automock functionality of Jest which allows us to isolate our JS modules when we test.

The previous image represents the metaphor that allows us to explain our unit testing strategy to newcomers.

You have to imagine that the application is a wall made of unit bricks (our ecmascript modules), our unit tests must test one by one the bricks in total independence from the others. Our functional tests are there to test the cement between the bricks.

To summarize, we could say that our E2E tests test what our application should do, and our unit tests make sure to check how it works.

Today there are more than 6000 unit tests that cover the application and allow to limit regressions.

👍

Jest is really a great library, fast, complete, well documented.
Unit tests help us a lot to understand several years later how it all works.
We always manage to unit test our code, and it complements our E2E tests well.
The automock is really handy for breaking down tests by modules.

👎

Sometimes we found ourselves limited by our E2E test stack and couldn’t rely solely on unit tests. We were missing something to be able to make sure that the cement between the bricks worked as we wanted it to. For this, a second test stack Jest was set up called “integration test” where the automock is disabled.
The abuse of Snapshot is dangerous for your health. The use of “Snapshot testing” can save time on the implementation of your tests but can reduce the quality. Having to review a 50 line object in Snapshot is neither easy nor relevant.
With the depreciation of EnzymeJS, we are forced to migrate to React Testing Library. It is of course possible to unit test components with this new library. Unfortunately, this is not really the spirit and the way to do it.React Testing Library pushes us not to play with shallow rendering.

Our principles

We try to always follow the following rules when asking the question “Should I add tests?“.

If our Pull Request introduces new user features, we need to integrate E2E test scenarios. Unit tests with Jest can complete / replace them accordingly.
If our Pull Request aims to fix a bug, it means that we are missing a test case. We must therefore try to add an E2E test or, failing that, a unit test.

It is while writing these lines that I think that these principles could very well be automated. 🤣

The project stays, the features don’t

“The second evolution of a feature is very often its removal.”

As a matter of principle, we want to make sure that every new feature in the application does not base its activation on simply being in the codebase. Typically, the lifecycle of a feature in a project can be as follows (in a Github Flow):

a person implements on a branch
the feature is merged on master
it is deployed in production
lives its feature life (sometimes with bugs and fixes)
the feature is not needed anymore
a person unravels the code and removes it
new deployment

To simplify some steps, we have implemented feature flipping on the project.

How does it work?

In our config there is a map key/value that lists all the features of the application associated with their activation status.

const featureFlipping = {
  myAwesomeFeature: false,
  anotherOne: true,
}

In our code, we have implemented conditional treatments that say “If this feature is activated then…“. This can change the rendering of a component, change the implementation of a Redux action or disable a route in our react-router.

But what’s the point?

We can develop new evolutions progressively by hiding them behind a configuration key. We deliver features in production without activating them.
In a test environment, we can overload this config to test features that are not yet activated in production.
In the case of a white label site, we can propose these features to our customers as possible options.
Before deleting code of a feature, we deactivate it and clean it up without risk.
Thanks to an in-house tool called Applaunch, this feature flipping config can be overloaded on time in a GUI without deployment. This allows us to activate features without putting the code into production. In the event of an incident, we can deactivate features that have been degraded.

To give you a more concrete example, between 2018 and 2020 we completely overhauled the application’s interface. This graphical evolution was just a featureFlipping key. The graphical redesign was not a reset of the project, we still live with both versions (as long as the switchover of all our customers is not completed).

A/B testing

Thanks to the great work of the backend and data teams, we were even able to extend the use of feature flipping by making this configuration modifiable for sub-groups of users.

This allows us to deploy new features on a smaller portion of users in order to compare our KPI.

Decision making, technical or product performance improvement, experimentation, the possibilities are numerous and we exploit them more and more.

The future flipping.

Based on an original idea by Florent Lepretre.

We regularly had the need to activate features at ~~very~~ early hours in the future. For that we had to be connected at a precise time on our computer to modify the configuration on the fly.

To avoid forgetting to do this, or doing it late, we made sure that a configuration key could be activated from a certain date. To do this, we evolved our selector redux which indicated if a feature was activated so that it could handle date formats and compare them to the current time.

const featureFlipping = {
  myAwesomeFeature: {
    offDate: '2021-07-12 20:30:00',
    onDate: '2021-07-12 19:30:00',
  },
}

Many coffees ☕️ at 9am have been saved by future flipping.

Monitor, Measure, Alert

To maintain a project as long as bedrock’s web application, testing, documentation and rigor are not enough. You also need visibility on what works in production.

“How do you know that the application you have in production right now is working as expected?”

We assume that no functionality works until it is monitored. Today, monitoring in Bedrock on the frontend side takes the form of different tools and different stacks. I could quote NewRelic, a Statsd, a ELK stack or even Youbora for the video.

To give you an example, each time a user starts a browsing session we send an anonymous monitoring Hit to increment a counter in Statsd. We then have to define a dashboard that displays the evolution of this number in a graph. If we observe a too important variation, it can allow us to detect an incident.

Monitoring also offers us solutions to understand and analyze a bug that occurred in the past. Understanding an incident, explaining it, finding its root cause are the possibilities that are open to you if you monitor your application. Monitoring can also allow you to better communicate with your customers about the impact of an incident and also to estimate the number of impacted users.

With the multiplication of our customers, monitoring our platforms well is not enough. Too much data, too many dashboards to monitor, it becomes very easy to miss something. So we started to complement our metrics monitoring with automatic alerting. Once we have enough confidence in the metrics, we can easily set up alerts that will warn us if there is an inconsistent value.

However, we try to always trigger alerts only when it is actionable. In other words, if an alert sounds, we have something to do. Sounding alerts that do not require immediate human action generates noise and wastes time.

Limit, monitor and update your dependencies

What goes out of date faster than your shadow in a web project based on javascript technologies are your dependencies. The ecosystem evolves rapidly and your dependencies can quickly become unmaintained, out of fashion or completely overhauled with big breaking changes.

We therefore try as much as possible to limit our dependencies and avoid adding them unnecessarily. A dependency is often very easy to add but it can become a real headache to remove.

The graphic component libraries (e.g. React bootstrap, Material Design) are a good example of dependencies that we do not want to introduce. They can make integration easier at first, but they often freeze the version of your component library later on. You don’t want to freeze the React version in your application for two form components.

Monitoring is also part of our dependency management routines. Since the addition of reporting security flaws in an NPM package, it is possible to know if a project has a dependency that contains a known security flaw with a simple command. So we have daily jobs on our projects that run the yarn audit command to force us to apply patches.

Dependency maintenance is greatly facilitated by our E2E test stack which sounds the alarm if the version upgrade generates a regression.

Today, except for security flaws, we update our dependencies “when we have time”, often at the end of sprint. We are not satisfied with this because some dependencies can be forgotten. I personally use tools like yarn outdated and Dependabot on my personal projects to automate the update of my dependencies.

Accepting your technical debt

A project will always accumulate technical debt. This is a fact. Whether it is voluntary or involuntary debt, a project that resists the years will inevitably accumulate debt. Even more so, if during all these years you keep adding features.

Since 2014, our best practices, our ways of doing things have evolved well. Sometimes we decided these changes but sometimes we underwent them (an example, the arrival of functional components with React and the Hooks api).

Our project is not completely “state of art” and we assume it.

We try to prioritize our refactoring topics on the parts of the application on which we have the most concern, the most pain. We consider that a part of the application that we don’t like but on which we don’t need to work (bring evolutions) doesn’t deserve that we refactor it.

I could name many features of our application that have not evolved functionally for several years. But since we have covered these features with E2E tests since the beginning, we didn’t really have to touch them.

As said above, the next evolution of a code feature is sometimes its deactivation. So why spend time rewriting the whole application?

In any case, the code becomes “legacy”.
As long as the features are tested, nothing obliges us to refactor everything permanently so that our entire codebase is state of art.
We focus on our pain points, we re-factor what we really need to evolve.

To summarize

The best practices presented here are obviously subjective and will not be perfectly/directly applicable in your contexts. However, I am convinced that they can probably help you identify what can make your project go from fun to stale. At Bedrock we have other practices in place that I haven’t listed here but that will be the occasion for a new article sometime.

Finally, if you want me to go into more detail on some of the chapters presented here, don’t hesitate to tell me, I could try to dedicate a specific article to it.

How to setup end to end tests with WebdriverIo on Github action ?

Antoine Caron — Fri, 13 Aug 2021 06:34:27 +0000

I recently set up an end-to-end testing stack to make sure I wasn’t going to introduce any functional regressions to my blog. With several years of experience using E2E (End to End) testing technologies, I still encountered some difficulties in setting it up.

In order to save you time I give you a step by step tuto for the installation of the tools necessary to have an efficient test stack in a few minutes.

Make it run locally first

You need to install some dependencies to your project first. For me the project was a quite simple Gatsby site, but you could settle it on whatever website you develop that have a package.json file. In this case I will start from a just initialised npm package. Make sure you have a Chromium or Chrome browser installed locally. We are really lucky because WebdriverIo teams have developed a CLI topic that does this job for you.

yarn add -D @wdio/cli

Then all you need is to trigger the initialisation of a new configuration. The CLI will show you a prompt you should follow.

yarn wdio config

Here is what you should do for each question:

Select first On my local machine.
You should definitely use cucumber, Gherkin language is so great to declare humanly readable user behaviors.
Choose the compiler you need, I personally use No. You could decide if you wannt to handle Babel or Typescript depending on you habits.
For the Where are your feature files located? I like to use the default value.
Same for step definitions, use default value.
Let’s see what tests WebdriverIo will autogenerate.
Do you want to use page objects ? I wouldn’t use that if it is the first time you setup those kind of testing stack, say n.
You should select spec reporter here.
Please select chromedriver service only.
Override the base url with you local context (for example, add the port on which you expose your app locally).

Normally the CLI generates some files for you and add the missing dependencies you need.

Here is my package.json

{
  "name": "example-wdio",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "devDependencies": {
    "@wdio/cli": "^7.9.1",
    "@wdio/cucumber-framework": "^7.9.1",
    "@wdio/local-runner": "^7.9.1",
    "@wdio/spec-reporter": "^7.9.0",
    "chromedriver": "^92.0.1",
    "wdio-chromedriver-service": "^7.2.0"
  }
}

You should see a login.feature file in ./features/ folder.

Feature: The Internet Guinea Pig Website

  Scenario Outline: As a user, I can log into the secure area

    Given I am on the login page
    When I login with <username> and <password>
    Then I should see a flash message saying <message>

    Examples:
      | username | password | message |
      | tomsmith | SuperSecretPassword! | You logged into a secure area! |
      | foobar | barfoo | Your username is invalid! |

With the steps definitions in ./step-definitions/steps.js

const { Given, When, Then } = require('@cucumber/cucumber')

Given(/^I am on the (\w+) page$/, async (page) => {
  await browser.url(`https://the-internet.herokuapp.com/${page}`)
})

When(/^I login with (\w+) and (.+)$/, async (username, password) => {
  await $('#username').setValue(username)
  await $('#password').setValue(password)
  await $('button[type="submit"]').click()
})

Then(/^I should see a flash message saying (.*)$/, async (message) => {
  await expect($('#flash')).toBeExisting()
  await expect($('#flash')).toHaveTextContaining(message)
})

Let’s see what those default example tests are doing ! For that, you just have to type this in your console and tada 🎉

yarn wdio run wdio.conf.js

Here is the log it will generate thanks to the spec reporter !

------------------------------------------------------------------
[chrome 92.0.4515.131 mac os x #0-0] Running: chrome (v92.0.4515.131) on mac os x
[chrome 92.0.4515.131 mac os x #0-0] Session ID: edd73da800a210e7c677c69cd064004f
[chrome 92.0.4515.131 mac os x #0-0]
[chrome 92.0.4515.131 mac os x #0-0] » /features/login.feature
[chrome 92.0.4515.131 mac os x #0-0] The Internet Guinea Pig Website
[chrome 92.0.4515.131 mac os x #0-0] As a user, I can log into the secure area
[chrome 92.0.4515.131 mac os x #0-0] ✓ Given I am on the login page
[chrome 92.0.4515.131 mac os x #0-0] ✓ When I login with tomsmith and SuperSecretPassword!
[chrome 92.0.4515.131 mac os x #0-0] ✓ Then I should see a flash message saying You logged into a secure area!
[chrome 92.0.4515.131 mac os x #0-0]
[chrome 92.0.4515.131 mac os x #0-0] As a user, I can log into the secure area
[chrome 92.0.4515.131 mac os x #0-0] ✓ Given I am on the login page
[chrome 92.0.4515.131 mac os x #0-0] ✓ When I login with foobar and barfoo
[chrome 92.0.4515.131 mac os x #0-0] ✓ Then I should see a flash message saying Your username is invalid!
[chrome 92.0.4515.131 mac os x #0-0]
[chrome 92.0.4515.131 mac os x #0-0] 6 passing (3s)

For now the tests are not testing your application at all. You will find many ressources on how to use Cucumber JS to write great test to describe and test your application features.

Configure the Github action workflow

Now that we have managed to run E2E tests on our machine, we just need to set up a continuous integration workflow that will automatically check on your Pull Request and on your main branch that all the tests are ok.

I use for most of my projects Github Action and I’m happy with it, so the following example will use this tool. However, the principle also works with a Gitlab, Jenkins or other pipeline.

With Github Action you need to setup a Yaml file to describe you workflow. Let’s create ./.github/workflows/continuous-integration.yml file in your project !

name: Continuous Integration

on:
  push:
    branches:
      - '**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # First you need to install a chromium browser in your runner
      - name: Install Chromium
        run: sudo apt-get install chromium-browser

      # You fetch the current ref
      - uses: actions/checkout@v2

      # Use Node version above 14.x you want to use
      - name: Use Node.js
        uses: actions/setup-node@v1
        with:
          node-version: 16.x

      # Install your dependencies (with yarn, npm no matter)
      - run: yarn install
        name: Install dependencies

      # This is where you could build your app
      # You could also start your server process (take a look at https://github.com/Slashgear/slashgear.github.io/blob/source/.github/workflows/continuous-integration.yml)

      # Run your test with the same command you uses locally
      - run: yarn wdio run wdio.conf.js
        name: Running E2E tests

Let’s try that ! 🚀

😭 Sadly you should face a very common error with E2E testing with chrome.

[0-0] 2021-08-12T20:34:12.293Z ERROR webdriver: Request failed with status 500 due to unknown error: unknown error: Chrome failed to start: exited abnormally.
[0-0] (unknown error: DevToolsActivePort file doesn't exist)
[0-0] (The process started from chrome location /usr/bin/google-chrome is no longer running, so ChromeDriver is assuming that Chrome has crashed.)
[0-0] 2021-08-12T20:34:12.293Z ERROR webdriver: #0 0x5631c488ba63 <unknown>

DevToolsActivePort file doesn't exist basically means your browser did not succeed to start. The main reason of the issue is the fact that you ask WebdriverIo to start Chrome browser with a Graphic User Interface on a ubuntu runner that don’t have a screen at all 😅.

We need to create a new configuration of Webdriver specific to github action that extends our basic one. Let’s create wdio-github.conf.js next to wdio.conf.js !

const basicConfig = require('./wdio.conf')

exports.config = {
  ...basicConfig.config,
  // We only need to override the Chrome configuration of capabilities
  capabilities: [
    {
      maxInstances: 5,
      browserName: 'chrome',
      acceptInsecureCerts: true,
      // We need to extends some Chrome flags in order to tell Chrome to run headless
      'goog:chromeOptions': {
        args: ['--headless', '--disable-gpu', '--disable-dev-shm-usage'],
      },
    },
  ],
}

We now just have to change the yarn wdio run command in our Github Workflow YAML file. You just need to push it and github will start it for you !

Setup multi browser configuration !

Chrome is not the only browser, and I hope it never will never be !

WebdriverIo is a great solution to run test on multiple Browsers. And I won’t show you here what great features you could use with remote running solution like BrowserStack or Saucelabs directly with WebdriverIo.

Let’s configure a Firefox locally !

Make sur to install a Java JDK 8 on your machine. Small trick for Macos users like me run brew install adoptopenjdk/openjdk/adoptopenjdk8 does the job !
Run yarn add -D @wdio/selenium-standalone-service to install selenium services working with WebdriverIo.
Make sure you have Firefox installed locally.
Now the last thing we need to do is to update our configuration to add firefox capabilities.

In wdio.conf.js, just replace capabilities and services arrays with this

{
  capabilites: [
    {
        maxInstances: 5,
        browserName: 'chrome',
        acceptInsecureCerts: true,
    },
    {
        maxInstances: 5,
        browserName: 'firefox',
        acceptInsecureCerts: true,
    }
  ],
  services: ['chromedriver', 'selenium-standalone'],
}

If you run the command yarn wdio run wdio.conf.js now, it will trigger both test on Firefox and Chrome and that is completely awesome !

The last thing we need to do is to update our Github specific configuration in order to make it work also in your continuous integration. You need to update capabilites too, in order to add Firefox and to make it boot Headless.

In wdio-github.conf.js

const basicConfig = require('./wdio.conf')

exports.config = {
  ...basicConfig.config,
  // We only need to override the Chrome configuration of capabilities
  capabilities: [
    {
      maxInstances: 5,
      browserName: 'chrome',
      acceptInsecureCerts: true,
      // We need to extends some Chrome flags in order to tell Chrome to run headless
      'goog:chromeOptions': {
        args: ['--headless', '--disable-gpu', '--disable-dev-shm-usage'],
      },
    },
    {
      maxInstances: 5,
      browserName: 'firefox',
      acceptInsecureCerts: true,
      'moz:firefoxOptions': {
        args: ['-headless'],
      },
    },
  ],
}

And that’s all folks !

Have fun covering your application with E2E tests ! Don’t hesitate to @ me on twitter if this How to helped you.

If you need to see the example application I used in this tutorial, take a look at this example Github repository.

Should we replace webpack by 🗻 Snowpack 🗻?️

Antoine Caron — Thu, 03 Jun 2021 21:27:34 +0000

After webpack, esbuild and vitejs, let’s take a look at snowpack. The latter seems to be making a name for itself in the bundler ecosystem for a few years now. So I suggest that we study its functionalities, its strong points but also its weak points.

Snowpack

What is Snowpack? It is a web application packager that offers :

a rich and powerful development experience
a production mode that offers the features necessary to optimize the assets of the site.

# npm:
npm install --save-dev snowpack
# yarn:
yarn add --dev snowpack

ESModule in the browser

Packagers such as webpack and rollup rely on the construction of a dependency tree that is analyzed and packaged at each modification. The build step of the modified files is still necessary, but the packaging operation (merging the different modules in the form of a bundle that is sent to the browser) is no longer necessary. Our browsers now know how to manage ESModules](https://caniuse.com/?search=esmodule), so it is no longer necessary to package our source modules to merge them.

This is the same idea that Evan You has taken up in Vite

With this principle, the modification of a file triggers only the build of this file, and this file only. You can have a project with thousands of javascript modules, the build time for each modification will not be affected. For dependencies (vendors), Snowpack builds them once and caches them to do it again only if they have changed.

Here is a diagram in the Snowpack doc showing the interest to avoid packaging in dev.

If you use a Create React App project, you just have to add Snowpack as a dependency, you don’t have to change anything if you didn’t extend the webpack config. I invite you to test snowpack with the template generators:

npx create-snowpack-app react-snowpack --template @snowpack/app-template-react

Don’t worry! Snowpack is not only compatible with React, you can use Vue, Svelte or just javascript.

A rich configuration (maybe too much)

Like webpack, snowpack proposes to configure its use by an object. I must admit that after playing with it quickly, I am a bit disappointed. I see a meager documentation page that seems to describe many parameterizable keys.

If you come from webpack, you won’t be lost, it’s very similar without being exactly the same.

Not touching the default configuration can be an excellent idea.

A nice collection of plugins

Snowpack is not that new. A community has built up to create a rich plugin ecosystem. Some of these plugins seem “core” because they are under the @snowpack scope but many packages are ported by a few people independent of the project. It’s reassuring without being reassuring, I’ve personally experienced webpack updates being blocked/delayed while waiting for compatibility of some plugins that were no longer maintained.

Beware of the plugins you use!

Contrary to Vite which natively offers a lot of nice features, snowpack works like webpack by relying on plugins to enrich the API. It’s a gamble, it can be complicated to keep this ecosystem of plugins up to date and efficient to continue to guarantee the interest of a migration to snowpack.

Server Side Rendering

Snowpack offers a solution to implement your applications with server-side rendering. It is clear that the need for SSR is still felt on our frontend applications for SEO or rendering performance reasons. Unfortunately, on the application packaging side, it is still complicated and it is often necessary to make two builds:

a build for the client aka the Browser
a build for the Node server

Double build, double punishment!

The technique proposed by Snowpack remains limited but it’s still correct. I propose a slight improvement of the implementation by adding the buffered server rendering mechanics.

const {readFileSync} = require('fs');
const {startServer} = require('snowpack');
const server = await startServer({ ... });
const runtime = server.getServerRuntime();

app.use(async (req, res, next) => {
  const importedComponent = await runtime.importModule('/dist/MyReactComponent.js');
  const MyReactComponent = importedComponent.exports.default;
  const html = ReactDOMServer.renderToNodeStream(React.createElement(MyReactComponent, null));
  // Directly write the head of page
  res.write(`
    <html>
    <head>
      <title>Hello 👋</title>
    </head>
    <body>
    <div id="app">
  `)
  // Render bufferized version of App
  html.pipe(res, { end: false });
  // When buffer end, we add the closing tags of page
  html.on('end', () => {
    res.write(`
      </div>
      </body>
      </html>
    `);
    res.end();
  });
});

Webpack, esbuild, quick, or snowpack ?

Clearly after this series of articles where I tried to study this new generation of tools to bundle applications, I must admit that I am very surprised. We can clearly see that the support of ES Modules in the browser marks the entry into a new era. As Sindre Sorhus reminds us in his latest article, with the end of Node 10 support and the capabilities of our current browsers, it is no longer necessary to target CJS.

Caching strategies and the use of CJS modules seem to be outdated for our needs in development environments. We can see that Vite and Snowpack offer this new mechanism which seems to be really efficient. Doing a once for all build of the libraries and of each source file is a great idea to not suffer from a too slow startup time of our big web applications.

Keep an eye on Esbuild

However, the performance of these new tools also relies heavily on Esbuild. The idea of using a more optimized stack to read, parse, combine JS or TS modules with languages that allow for finer IO and memory management is really the keystone of this new generation of tools. Even before choosing whether to stay with webpack, or use Vite and Snowpack, it is certain that Esbuild will have to be followed closely. This lib has not finished surprising us. You should also look at a tool like SWC which is a direct competitor of Esbuild. There are certainly other tools being created at the moment.

I use webpack and have configured it a lot

If you are in this situation, you may unfortunately be forced to keep webpack. This is not bad news, it is a very good tool that is far from being obsolete. It is likely that the webpack team will come up with new performance improvements, perhaps through the use of ESModules.

You can also try to use snowpack in a development environment. There is a plugin to use webpack in the snowpack prod build.

I really want to reduce the configuration of my application build

If you don’t want to keep your webpack configuration files anymore, which can be sometimes difficult to maintain, the alternative proposed by Vite can be a great option. Just keep in mind that this solution is still young.

If you are going to use Vite, I suggest that you minimize the configuration you can do to it. This will make it easier for you to keep up with the new versions that are likely to arrive in the coming months.

I use a CLI that manages my build configuration for me

You are using VueCLI, CRA, or other and you have not ejected your configuration. You don’t like to touch the build configuration of your application because the tools are complex and you don’t want to spend a lot of time configuring them. So I recommend you to stay as much as possible with the default configuration of your project as long as its performance does not bother you.

However, nothing prevents you from testing tools like Vite that work directly without configuration with your already generated projects. If the startup time of your development environment becomes too important, this can really be an interesting solution for you.

And it’s already the end?

I think I’ve covered the new tools proposed by the community to package our web applications. If you have other tools that would be interesting to look at, don’t hesitate to suggest them to me on a social network like Twitter. See you soon for new javascript peregrinations !👋

Thanks to Jérémie for the review 🤗

Vite, a new webpack killer ?!😮

Antoine Caron — Fri, 26 Mar 2021 00:00:00 +0000

After having dealt on this blog in several articles about webpack, I have started a new series of articles about new generation bundlers. It seems that we are now entering a new era of web tooling.

Having introduced esbuild and its interesting features, it seems logical to me to deal with the “little brothers” bundlers. So let’s start with Vite, a project from the VueJS community and started by Evan You.

Same starting point

With Vite we are in the same situation as with esbuild. Globally the community is happy with the current tools even if they have some performance issues.

As I said in my previous article, having a big JS project today often means having a dev and prod environment that is sometimes a bit slow. Between the choice of tools that do not sufficiently exploit parallelization or memory optimization, or repetitive operations that exploit caching very little, it is easy to identify culprits for these slowness.

NB: I have proposed some solutions to improve the performance of your webpack build in this article.

Moreover, the second generation tools (like webpack, Rollup, Parcel) could not handle from the beginning recent features of our browsers like ESmodules.

What is the idea?

The revolutionary idea of Vite is to combine two tools for two different needs in order to optimize the build to be as fast as possible. The two tools that make up Vite are esbuild and Rollup, so nothing new. But why two bundling tools? Basically, for two reasons:

Our dependencies don’t change often, so re-evaluating their module tree at each build is not necessary. We can generate the bundle of our vendor once and for all with an optimized tool like esbuild. This bundler is very fast and allows a quick start of the server.
The modules in our source code are subject to a lot of changes unlike the dependencies. So Vite uses another treatment based on ESM that works natively on recent browsers.

Feel free to read this doc page for more details.

In fact, how does it work?

In order to play a little with the tool, I propose a small presentation through an example project. Let’s start by creating an example project. I show you here how to create it and put you the link of the github repository in which I published it.

mkdir "example-vite"
cd "example-vite"

git init
yarn init -y

Installing Vite is very easy, you just need a dependency.

yarn add -D vite

For the purpose of this example, I propose an example with React (there are already many examples with Vue 😉 )

yarn add react react-dom

Let’s add 3 usual commands to launch Vite in the package.json file

package.json

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "serve": "vite preview"
  }
}

Finally, we need some small source files for Vite to play with.

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Example Application with Vite</title>
  </head>
  <body>
    <div id="app"></div>
    <script type="module" src="/src/main.jsx"></script>
  </body>
</html>

src/main.jsx

import React from 'react'
import ReactDOM from 'react-dom'

ReactDOM.render(
  <React.StrictMode>
    <h1>Hello world dear readers ! </h1>
  </React.StrictMode>,
  document.getElementById('app')
)

Now you just have to start the development server with this command.

yarn dev

🎉 Normally, within milliseconds Vite has started a server and if you go to https://localhost:3000 that presents you with this beautiful application.

Let’s not lie, it’s a bit sad, let’s see how Vite does if we add some CSS. Let’s put a beautiful color chartreuse to this title. Let’s add the following stylesheet.

src/index.css

h1 {
  color: chartreuse;
}

Then we just need to add an import to this new file.src/main.jsx

import './index.css'

There, now you have a beautiful color that clearly lacks contrast to be accessible!

If you now try to run the yarn build command, you can see that Vite will build you a dist folder. Without any settings I have these different resources ready to be deployed on a static server.

We can observe that natively Vite exports 2 javascript bundles (1 for the sources, 1 for the vendors/dependencies) and a CSS bundle that exports the style that has been imported in your application. And this is clearly a big plus of Vite compared to the competition of other tools (although parcel offers some of the same logic). The build is extremely fast and does what you would expect it to do without having to configure it. Sorry but I think it’s great!

I don’t know if you know react-refresh, the official React package that allows you to optimize the auto-refresh of a React application. This package allows you to update your React components on the fly without them losing their state.Vite even though it was born out of the VueJS community, is not specifically oriented towards a frontend framework. Tools like react-refresh are therefore not included by default. So you have to define it in the configuration. Unfortunately, Vite doesn’t fare any better than the other tools; we are forced to define yet another config file at the root of the project.

So let’s install the plugin:

yarn add -D @vitejs/plugin-react-refresh

vite.config.js

import { defineConfig } from 'vite'
import reactRefresh from '@vitejs/plugin-react-refresh'

export default defineConfig({
  plugins: [reactRefresh()],
})

Now I wanted to test some of the more advanced features that you can expect from a quality bundler. So I set up a single page application that uses lazy loading. I won’t show you how I did it in this article, it would be too long but you can go directly to test it in your browser.

So clearly for lazy loading it’s easy with Vite, I’m amazed! The tool immediately detects my use of the dynamic import import() to generate a separate chunk for the JS but also the CSS.

const Content = React.lazy(() => import('./lazy'))

The strengths of Vite

It is clear that Vite has many nice features and advantages. Besides its incredible speed, I would like to note that this bundler offers a really well thought out autoconfiguration.

In the demo I gave you earlier, I didn’t show you that Vite handles natively and without configuration static files, Web Workers, WASM binaries. But it doesn’t stop there, we have to admit that this magical tool also natively supports JSX and Typescript.

When it comes to style management, Vite is not to be outdone. Without any plugin or configuration, it allows you to manage CSS @imports, preprocessors like SASS and LESS, CSS modules and even the postprocessor PostCSS (if you define a configuration).

More anecdotally, Vite knows how to manage your .env file to manage your environment variables thanks to dotenv.

But the feature that completely blew me away was the rather simple setup of the SSR.

This is the first time I’m talking about a bundler that natively handles Server Side Rendering. I use other tools in production for the different applications I develop. Unfortunately, it is still very complicated to set up such an architecture (even with tools like Webpack).

So we can see that developers are mainly turning to turnkey solutions like Next and Nuxt to manage these issues for them. This is not a bad thing in itself. However, I think that it is sometimes necessary in some projects to take control of this functionality for business needs. So we can only be happy that tools like Vite have thought about it. I invite you to go read this page of the documentation of Vite to understand how to implement this.

So we stop using webpack?

After this laudatory presentation of this tool, one could ask the question yes. However, you should not forget a simple rule.

Everything that a tool tends to do magically for you often becomes much more complicated to customize.

The many choices Vite seems to make to improve the developer experience worry me a bit. I’m a bit afraid that all this default configuration will be complicated to maintain by the Vite teams.

Contrary to esbuild which has the motto “I want to offer a tool that does few things but does them very well”, we have here a tool that makes a lot of promises. However, we must recognize that Vite also offers to use and define plugins to extend its functionalities without making them native to the main tool.

Moreover, it should not be forgotten that Vite is also based on Rollup, a second generation bundler that benefits from a rich ecosystem of plugins that are mostly compatible. But the Rollup configuration is very complicated to edit and maintain, so I hope you won’t have to touch it if you are tempted to test Vite on your applications.

I would like to point out that some tools like VuePress offer today an alternative Vitepress which uses Vite as a bundler.

Before jumping on the Vite solution, I suggest you to test another third generation bundler which is much talked about: Snowpack

Stay tuned!

Esbuild, the incredibly fast 💨 and promising bundler 📈!

Antoine Caron — Sat, 13 Mar 2021 00:00:00 +0000

I’ve been playing with JS bundlers for several years. Still convinced of the necessity of using these tools (don’t let me believe that you don’t package your JS modules in production 😅), I played a lot with webpack. Especially for performance, optimization and custom plugins usage issues.

I still think that in 2021, webpack is the most industrial and successful solution to bundle my web applications. I hear that tools like parcel and rollup are still good alternatives. However, webpack probably has the biggest community and is used by many projects.

But let’s face it, today we are satisfied with these bundling tools despite their poor performance. I work every day on a project with several thousands of “modules” solved by webpack and it is sometimes a pain 🥱.

Despite an intensive use of cache and workers, webpack shows some limitations to package large applications.

Why does esbuild look interesting ?

I can’t think of an easier way to express it than to explain it to you simply:

The first time I ran esbuild on my test web app, I thought it crashed when in fact it ran at an absolutely insane speed.

To install it, it’s not complicated:

yarn add -D esbuild

npm install -D esbuild

Or even with NPX

npx esbuild --version

Being written in Go, a WASM version and binaries for the main architectures are available.esbuild bets on native Go to take advantage of a maximum of parallelization solutions and a better memory management.

A lean API by design

Globally the API of esbuild is really simple, in 30 minutes you have read all the docs of possible settings. This is far from the 3-4 hours needed to read the whole documentation of a webpack for example. In spite of a configuration that might seem limited, I am still pleasantly surprised. I have the impression that we are really close to having the “right grammar” that we need to do bundling.

esbuild offers 3 consumption modes:

CLI

esbuild app.jsx --bundle --minify --sourcemap --target=chrome58,firefox57,safari11,edge16

GO

package main

import "github.com/evanw/esbuild/pkg/api"
import "os"

func main() {
  result := api.Build(api.BuildOptions{
    EntryPoints: []string{"app.jsx"},
    Bundle: true,
    MinifyWhitespace: true,
    MinifyIdentifiers: true,
    MinifySyntax: true,
    Engines: []api.Engine{
      {api.EngineChrome, "58"},
      {api.EngineFirefox, "57"},
      {api.EngineSafari, "11"},
      {api.EngineEdge, "16"},
    },
    Write: true,
  })

  if len(result.Errors) > 0 {
    os.Exit(1)
  }
}

JS

require('esbuild').buildSync({
  entryPoints: ['app.jsx'],
  bundle: true,
  minify: true,
  sourcemap: true,
  target: ['chrome58', 'firefox57', 'safari11', 'edge16'],
  outfile: 'out.js',
})

In my opinion, the CLI is still very practical for testing things, but in a more “industrial” use, we still prefer the JS or GO format.

Plugin mechanics

Evan Wallace the creator and core maintainer of esbuild makes no secret of the fact that he doesn’t want his tool to meet 100% of the needs that one can have in the web world. However, this doesn’t mean that we can’t use this tool in specific cases.

As we can see with other bundlers, esbuild offers the mechanics of plugins that allow you to do many things. To avoid maintaining all these specific needs, the creator relies on the community to create all the plugins you could want. And clearly, the community is there, I let you see this page that lists some plugins.

The most interesting features

I’m not going to list here the features that seem to me the heart of a Web bundler like code splitting, injection, minification. However, I was surprised by some features that are not found elsewhere.

An easy to understand architecture

Clearly, what makes the strength of esbuild compared to its competitors is its architecture which can be summarized simply. It is easy to understand that by combining the parallelization of the build steps and the reduction of the number of readings of the AST. I invite you to read more explanations in the doc.

Browser targets

By default esbuild allows you to define the target of your build. What level of javascript do you want to achieve?

Usually we use a suite of tools like @babel/preset-env and a browserlist to make sure we generate the JS compatible with our targeting. Babel is great, I use it every day, but piling up different tools for bundling is clearly not a good solution in my eyes. It adds a lot of complexity:

instead of learning to use a simple bundler tool, I have to learn a targeted transpilation tool on top of that
I have to maintain two dependencies
going through a third party librairy can reduce performances (this is a bit the bet of esbuild)

The server mode

esbuild is so fast that it can afford to expose you an HTTP server on a folder that contains the result of your compilation on each request. Other tools usually rely on a watch mode that watches for files that change to start a build.

The watch mode also exists with esbuild, but the serve mode seems to me even nicer because you just have to refresh your browser to have the latest version of your application locally.

require('esbuild')
  .serve(
    {
      servedir: 'www',
    },
    {
      entryPoints: ['src/app.js'],
      outdir: 'www/js',
      bundle: true,
    }
  )
  .then(server => {
    // Call "stop" on the web server when you're done
    server.stop()
  })

But then we stop everything and go on it?

Let’s save time, the answer for me is clearly no.

As the creator says in the FAQ of the doc in all honesty, the project is not to be considered as being in alpha. However, the tool itself does not yet have all the features that would make it a good replacement for the previous generation bundlers. I’m thinking in particular of the absence of native HMR, or of a perfectible splitting code.

However, one should not remain closed on this question. Clearly esbuild has very strong points that are missing in the current ecosystem. The community, still in its infancy, is rather active and the exchanges in the Issues and PR of the repo are very interesting.

What I really appreciate in this project are the parts taken: a focus on performance, an API that remains simple. Finally, for once a bundler doesn’t have 1000 dependencies and add 100Mb in my node_modules folder, it’s nice enough to note.

I’ll finish by saying that esbuild is not the only alternative that is offered to us in this new generation of bundler. I intend to do this kind of analysis on tools like Vite or Snowpack.

🎄 Advent of Code 2020 🎄: my solutions with JS

Antoine Caron — Fri, 04 Dec 2020 00:00:00 +0000

I decided this year to try the adventofcode2020 challenge in JS to see. I published the solutions I found in a public repository on Github. Not sure I will find solution for the upcoming challenges. 😅

Slashgear / advent-of-code

Personal implementation in JS of https://adventofcode.com/ challenge, don't hesitate to take a look if your are stuck

advent-of-code by Slashgear

In this repository you can find all the advent-of-code challenges that I passed. All solutions are in JS only (You can run them with Node). Feel free to look at my solutions for inspiration.

Solutions are sorted by year and by day in the packages folder.

packages/
  2019/
    day-1/
      ..
    day-2/
      ..
  2020/
     day-1/
      ..
    day-2/
      ..
    day-3/
      ..
  ..

View on GitHub

Project is a lerna monorepo structure showing solution by years and days.

packages/
  2019/
    day-1/
      ..
    day-2/
      ..
  2020/
     day-1/
      ..
    day-2/
      ..
    day-3/
      ..
    day-4/
      ..
  ..

For now, you can find solution for: