
Lancé fin 2017, [Tailwind](https://tailwindcss.com) s'est très rapidement fait une solide réputation dans l'univers des frameworks CSS. Désormais très populaire (plus de 63 000 étoiles sur Github) et utilisé sur une multitude de sites, ce package reste controversé et est souvent accusé de réinventer la roue.

Pour me faire ma propre idée, je l'ai testé sur un projet Next.js (disponible [ici](https://jujuetcaillou.fr)). Pour quel bilan ?

## A quoi ça sert ?

Tailwind, c'est un concept simple. Le framework apporte un lot de **classes utilitaires** permettant de styliser sans écrire de CSS directement. Du CSS inline camouflé derrière d'autres noms.

Prenons un exemple d'un bloc HTML des plus basiques, stylisé en CSS.

```html
<div class="main-content">
    <h1>Titre</h1>
    <p>Contenu</p>
</div>

<style>
    .main-content {
        display: flex;
        padding: 1rem;
    }

    .main-content > h1 {
        font-size: 1.5rem;
        color: red;
    }

    .main-content > p {
        color: blue;
        padding-top: 0.5rem;
    }
</style>
```

Avec Tailwind, voici le code à écrire pour reproduire à l'identique l'exemple.

```html
<div class="p-4 flex">
    <h1 class="text-2xl text-red-600">
        Titre
    </h1>
    <p class="pt-2 text-blue-600">
        Contenu
    </p>
</div>
```

En regardant ce code, on peut se demander si ce n'est pas un retour en arrière. Un retour à une époque où écrire du CSS inline était courant avant de devenir une honte, une mauvaise pratique. La [séparation des préoccupations](https://fr.wikipedia.org/wiki/Séparation_des_préoccupations) (separation of concerns) est ici complètement bafouée.

Et ce n'est pas le pire à encaisser. L'exemple ci-dessus est simpliste et court mais dans un cas réel, il n'est pas rare d'associer un nombre conséquent de propriétés CSS à un bloc de code. On se retrouve alors avec une ligne **interminable** remplie de classes utilitaires.

```html
<div class="p-6 max-w-md flex items-center justify-center rounded-xl bg-white cursor-pointer shadow-lg hover:p-10 hover:bg-black">
    ...
</div>
```

Pour ma part, c'est le moment où j'ai failli lâcher l'affaire. Et je ne suis visiblement pas le seul dans ce cas vu ce qui est écrit en [introduction de la documentation](https://tailwindcss.com/docs/utility-first#overview) de Tailwind.

<Quote
content="Now I know what you’re thinking, “this is an atrocity, what a horrible mess!” and you’re right, it’s kind of ugly. In fact it’s just about impossible to think this is a good idea the first time you see it — you have to actually try it."
/>

Qu'on peut traduire brièvement par "*Vous pensez que c'est horrible, et c'est vrai, c'est assez moche. Mais même s'il est impossible de penser que c'est une bonne idée au premier abord, vous devez l'essayer.*".

Ce que j'ai fini par faire, pour mon plus grand bonheur.

## De sérieux avantages

Un élément qui revient souvent concernant les qualités de Tailwind est sa capacité à produire un fichier CSS le plus petit possible. Le framework se charge de générer un fichier ne contenant que les classes utilitaires présentes au sein du code du projet, ce qui évite les surcharges inutiles qu'on pouvait fréquemment voir avec l'importation complète de **Bootstrap** par exemple.

Je trouve cependant que ses qualités majeures se trouvent ailleurs, à l'usage.

### Des composants sinon rien

Dupliquer du code n'est jamais agréable à faire et complique la maintenance sur la durée. Mais il fréquent de voir des blocs entiers de code copiés pour diverses raisons (manque de temps, fatigue, mauvaises pratiques, ...).

Le fait d'utiliser Tailwind **décourage** très fortement cette pratique et dirige naturellement vers la création de composants dédiés.

Il est relativement facile d'envisager de copier ceci

```html
<span class="mon-mot-en-gros">Bidule</span>
```

si le css associé est dans un fichier séparé.

```css
.mon-mot-en-gros {
    font-size: 3rem;
    font-weight: bold;
    color: red;
    text-decoration: underline;
    line-height: 2rem;
    text-transform: uppercase;
}

.mon-mot-en-gros:hover {
    font-size: 6rem;
    color: blue;
}
```

Il sera plus difficile de se sentir à l'aise si le code à copier est plus conséquent.

```html
<span class="text-5xl hover:text-8xl font-bold text-red-600 hover:text-blue-600 underline leading-8 uppercase">
    Bidule
</span>
```

Le découpage en composants devient d'autant plus primordial ici, ce qui est bien souvent une excellente pratique. Une contrainte de Tailwind devient un avantage à l'usage.

### Fin de la guerre des fichiers CSS

En repartant de l'exemple précédent, on peut se demander s'il est bien grave de dupliquer un si petit bout de code si son CSS est rangé dans son propre fichier. Mais après avoir travaillé sur des dizaines de projets aux multiples fichiers CSS (ou SASS), j'ai constaté que l'organisation du CSS représente quasiment toujours un souci à terme.

Plusieurs écoles s'affrontent. L'école du gros fichier CSS unique, celle qui propose un fichier par composant, celle [qui intègre le CSS dans le JS](https://cssinjs.org). J'en oublie certainement d'autres.

Pour avoir déjà testé les deux premières, je ne les trouve pas satisfaisantes.

- Le fichier unique est ingérable pour des projets conséquents.
- Le fichier par composant est déjà mieux sur le papier. Mais il est dur d'éviter les conflits avec des fichiers CSS plus globaux.

Tailwind s'affranchit de ces débats. Plus besoin de chercher la ligne CSS coupable du visuel désastreux de notre bouton, il suffit d'ouvrir le fichier du composant associé et lire les classes utilitaires.

### Donner des noms c'est long

Probablement le point qui m'apporte le plus de confort. Je ne me rendais pas compte du temps perdu à chercher des noms pour les classes CSS.
C'est pourtant un point connu dans le domaine informatique, avec la fameuse citation de Phil Karlton :

<Quote
content="There are only two hard things in Computer Science: cache invalidation and naming things."
/>

Chercher des noms, éviter les conflits, garder une cohérence, avoir des noms les plus limpides possibles. Tout ceci est bien plus **chronophage** que l'on ne pourrait le penser.

Supprimer totalement cette contrainte grâce à Tailwind s'est révélé être un bol d'air frais pour l'esprit. Je peux me concentrer sur la conception de mon composant, sur son usage, plutôt que sur le fait de trouver un nom pour les éléments qu'il comprend.

## Quelques contraintes

Rien n'est jamais parfait, Tailwind ne fait pas exception. Si son usage ne fait pas l'unanimité, c'est qu'il comprend son lot de défauts.

### Le CSS est standard et fiable

Le plus gros point noir à mes yeux. Tailwind reste un package à installer et demande une compilation pour générer au final ... du CSS.

Un projet directement stylisé grâce à du CSS sera compris par un navigateur web, sans efforts supplémentaires. Le code reste **valide** sur une longue période.

A contrario, si Tailwind disparaît de la toile, les projets l'utilisant deviennent soudainement obsolètes. Cependant ce scénario reste peu probable et la conséquence n'est pas insurmontable. Il faudrait alors réécrire des classes CSS pour remplacer les classes utilitaires de Tailwind. Ce serait pénible mais le risque paraît faible et la conséquence peu coûteuse.

### Un apprentissage supplémentaire

Utiliser Tailwind, cela revient à manipuler des dizaines de classes utilitaires. Comme pour Bootstrap, on se retrouve à devoir **apprendre** une grande quantité de noms si l'on veut les utiliser rapidement sans naviguer en permanence dans la documentation.

De plus, on apprend à utiliser un outil spécifique et ces connaissances ne seront pas applicables ailleurs, contrairement à l'apprentissage du CSS.

Heureusement cette contrainte est adoucie grâce aux noms des classes utilitaires, qui sont assez instinctifs. On peut aussi avoir une autocomplétion [au sein de VSCode](https://tailwindcss.com/docs/editor-setup#intelli-sense-for-vs-code).

Pour ma part je garde toujours un onglet ouvert sur la documentation officielle mais je n'y jette un oeil que rarement désormais. Après un seul projet réalisé avec Tailwind.

### Des lignes interminables

Vous vous souvenez de l'exemple du début ?

```html
<div class="p-6 max-w-md flex items-center justify-center rounded-xl bg-white cursor-pointer shadow-lg hover:p-10 hover:bg-black">
    ...
</div>
```

Pour ma part, je n'apprécie pas du tout les lignes à rallonge et j'aime voir tout le code à l'écran. Sans avoir à scroller sur la droite.

Les premières longues lignes de classes utilitaires se sont révélées assez **douloureuses** à écrire. Je voyais ce défaut comme un point bloquant, ce qui m'a amené à chercher des solutions.

La documentation officielle propose [d'organiser les classes automatiquement](https://tailwindcss.com/docs/editor-setup#automatic-class-sorting-with-prettier) (dans l'ordre conseillé par le framework) grâce à Prettier. Un bon début pour éviter le chaos mais pas une réponse à mon problème.

J'ai alors découvert [clsx](https://github.com/lukeed/clsx). Un tout petit package (228B) qui facilite l'écriture des classes CSS dans un projet React. A la fois bien pratique pour écrire des classes de façon conditionnelle, cet utilitaire me permet de ranger mes classes Tailwind d'une façon qui me convient bien mieux.

Avec clsx, l'exemple devient le code suivant :

```jsx
<div
    className={clsx(
        'p-6 hover:p-10',
        'max-w-md',
        'flex items-center justify-center',
        'rounded-xl',
        'bg-white hover:bg-black',
        'cursor-pointer',
        'shadow-lg'
    )}
>
    ...
</div>
```


Au premier abord, ce n'est pas très séduisant. Beaucoup de lignes de code pour une simple balise. Pourtant, je suis très **satisfait** de cette solution.

Le nombre de lignes est un petit défaut mais vient lui aussi encourager la découpe du code en composants. En séparant les fonctionnalités en petits éléments, ces lignes supplémentaires ne représentent pas une contrainte.

Je trouve aussi plus facile de voir en un coup d'oeil les choix visuels effectués sur ce bloc de code. Pas besoin d'ouvrir un fichier CSS pour se renseigner ni de scroller. Si je veux rajouter une condition (hover, media query), je peux le faire rapidement sur la ligne d'une classe utilitaire.

## Tailwind : c'est oui ou c'est non ?

Mon bilan ne contiendra pas de surprise : Tailwind c'est **un grand oui** !

Ses avantages me libèrent considérablement l'esprit et ses contraintes sont facilement contournées. Elles deviennent même positives lorsqu'elles encouragent la création de composants plus petits, plus facilement modifiables et testables. Ce qui peut aussi encourager l'utilisation de [Storybook](https://storybook.js.org).

Son succès me semble amplement **mérité**. Si j'ai pu finaliser le projet [Juju & Caillou](https://jujuetcaillou.fr) (un super site de recettes de cuisine) c'est en partie grâce à Tailwind. J'ai pu itérer plus rapidement, garder davantage de motivation sur la durée, tout en ayant un code plus facile à faire évoluer.

Ses créateurs n'ont pas menti : il faut le tester avant de juger.

<NewsletterSignUp />


Les avantages et inconvénients de ce framework populaire, qui mérite son succès.

Je n'étais pourtant pas du tout emballé au départ.

Comment Tailwind CSS m'est devenu indispensable


Face aux bouleversements provoqués par le tsunami qu'est l'IA, la réflexion demeure complexe. Les usages innovants se multiplient, les questionnements éthiques évoluent continuellement. Je suis longtemps resté attentif, observant à distance cet océan d'informations se déchaîner.

Je reste sceptique et méfiant concernant l'intelligence artificielle générative, particulièrement dans les domaines artistiques. Cependant, cette technologie semble pertinente pour assister l'humain dans des tâches précises, techniques, qui comportent de la répétitivité.

Tester **GitHub Copilot** est alors devenu une évidence. D'autant plus avec 30 jours d'essai gratuit.

<InfoAside>Cet article n'est en aucun cas sponsorisé.</InfoAside>

## Mon expérience avec Copilot

### Le premier mois

A l'aube de notre collaboration Copilot m'a accompagné sur mon projet de refonte de [devzen.fr](https://devzen.fr), mon site vitrine. Je passais de [Scully](https://scully.io) à [Nuxt](https://nuxt.com), d'Angular à Vue.js. Le processus n'était pas complexe mais fastidieux. Surtout concernant la partie visuelle pour effectuer une transition CSS => Tailwind.

_(Un [article](/article/comment-tailwind-css-m-est-devenu-indispensable) est disponible pour parler de ma relation avec Tailwind)_

Dans ce cadre, Copilot s'est révélé comme un assistant discret mais précieux, nécessitant peu d'interactions directes pour proposer des solutions adéquates.

Plus surprenant, il s'est mis en valeur en proposant l'intégralité du style de certains composants, avec une justesse assez admirable. Quelques retouches nécessaires mais une excellente base de travail.

### Le second mois

Cette fois-ci, objectif totalement différent. Je devais découvrir le langage [Go](https://go.dev) et réaliser un petit projet d'entraînement.

Après un parcours complet de l'excellent [tutorial d'apprentissage](https://go.dev/tour/welcome/1) officiel, il était temps de mettre les mains dans le code. Et d'enfin profiter pleinement du potentiel de l'outil de Microsoft.

-   Au lancement, j'utilise Copilot Chat pour lui poser quelques questions génériques. Ce qu'il conseille comme organisation de dossiers, quelles sont les conventions de nommage en Go. Les réponses sont détaillées, toujours fournies avec des exemples clairs et concis.
-   Pendant le développement, il propose régulièrement de finir les lignes, m'évitant de devoir chercher une syntaxe que je ne maîtrise pas encore.
-   Il m'explique les erreurs que je peux rencontrer et me propose des moyens de les corriger
-   Il peut me donner son avis sur le code que j'écris et me proposer des alternatives plus efficaces

<BlogImage
    src="/images/github-copilot-apres-2-mois/copilot_question_folder_structure.png"
    alt="Réponse de Copilot sur la façon d'organiser un projet Go"
    subtitle="Réponse efficace et pertinente"
/>

Les moments "page blanche" auraient pu être dix fois plus nombreux sans l'accompagnement de Copilot. En cas d'incertitude sur la marche à suivre, je me tourne de plus en plus vers son Chat pour des échanges, contribuant également à clarifier mes pensées, un effet secondaire intéressant.

Après ces deux mois, j'ai pu tirer un premier bilan de mon expérience.

## Points positifs

### Libération de charge mentale

Un élément difficilement quantifiable mais central est la capacité de l'outil à libérer l'esprit. La valeur ajoutée d'un développeur n'est pas dans sa capacité à retenir des quantités astronomiques de syntaxes, ni dans sa capacité à pondre du code sans jamais regarder la moindre documentation.

Quand Copilot propose de finir une ligne, il a compris l'intention et évite d'éventuelles pauses pour trouver la bonne façon de l'écrire.

### Garde le focus sur l'IDE

Dans le même ordre d'idée, l'usage de cette IA m'évite des allers-retours entre mon navigateur et mon IDE.

Les questions sont posées directement dans VSCode, les réponses arrivent rapidement. Le besoin de sortir de ce contexte se fait plus faible.

<BlogImage
    src="/images/github-copilot-apres-2-mois/copilot_inside_vscode.png"
    alt="Copilot est directement intégré dans VSCode"
/>

### Le meilleur ami du dev

S'il y a bien quelque chose que les devs détestent, ce sont les tâches répétitives. Pour notre plus grand bonheur, c'est un exercise idéal pour une machine.

Copilot ne déroge pas à ce principe et est un allié de poids pour s'alléger la pénibilité de certaines corvées.

### Fiable concernant ce qui est populaire

Un risque permanent lorsqu'on utilise une IA, c'est de se retrouver face à de fausses informations énoncées comme véridiques. Ce risque existe aussi avec Copilot mais semble faible lorsque le sujet est populaire en ligne. Les questions concernant un langage réputé ou un framework déjà bien adopté sont pertinentes l'immense majorité du temps.

Pour apprendre le Go, l'outil s'est révélé fiable sur l'ensemble de mes interrogations.

### On se sent moins seul.e

On ne remplace pas une interaction humaine en écrivant à Copilot.

<BlogImage
    src="/images/github-copilot-apres-2-mois/copilot_feelings.png"
    alt="Copilot nous rappelle qu'il n'est pas un être humain."
    subtitle="😢"
/>

Mais on peut tout de même ressentir moins de solitude dans ce travail qui demande parfois de rester de longues heures seul.e devant l'écran. Le fait de devoir formuler des phrases compréhensibles par la machine donne des échanges plus intéressants qu'en tapant quelques recherches sur Google.

## Points négatifs

### Peu adapté à la complexité

Copilot brille sur des demandes fréquentes ou des logiques déjà abordées de multiples fois en ligne. C'est normal, c'est de là qu'il tire son savoir.

Si les problèmes rencontrés sont plus rares ou les questions plus complexes, l'IA a encore des progrès à faire. Mais en gardant à l'esprit qu'il a avant tout un rôle d'assistant, ce n'est pas choquant.

### Jamais totalement fiable

Bien que les réponses de Copilot aient été vantées jusqu'à présent, il est impossible de lui faire totalement confiance. Un degré de doute doit toujours subsister pour éviter d'appliquer aveuglément ce qu'il propose.

Mais cette logique s'applique aussi au contenu trouvé en ligne, ce n'est pas spécifique à l'IA.

### Inadapté pour des technologies récentes

Comme pour ChatGPT, Copilot est limité dans ses connaissances. Certaines nouveautés ne sont pas forcément connus de l'outil qui admet sans langue de bois qu'il n'est pas apte à fournir des informations récentes.

<BlogImage
    src="/images/github-copilot-apres-2-mois/copilot_astro.png"
    alt="Copilot ne connaît pas les changements récents du framework Astro."
/>

Pour du développement, un domaine qui évolue si vite, cela peut être vu comme un défaut majeur. Mais je ne pense pas qu'il faille aborder l'outil sous cet angle.

## Conclusion

Ma période d'essai de Copilot s'est terminée. Vais-je prolonger l'aventure et débourser 10€ chaque mois pour continuer de l'utiliser ?

La réponse est un **OUI** assez net. A ce tarif, quelques gains de temps mensuels suffiraient à justifier l'achat. Mon expérience actuelle de l'outil me fait envisager des bénéfices bien supérieurs au coût qu'il représente.

Si on attend de Copilot qu'il génère tout notre projet à notre place, la déception risque d'être présente.
L'intelligence artificelle utilisée comme un remplacement complet de l'humain n'est pas une voie que j'imagine viable à long terme. Et va à l'encontre de mes valeurs.

Mais s'assister d'un Copilot dans ses tâches de développement permet de se concentrer sur son expertise tout en lui déléguant une partie du travail. En collaborant avec lui. En le voyant comme un outil d'autocomplétion boosté aux hormones, comme un moteur de recherche sous stéroïdes. Sous cet angle, son usage est un plaisir quotidien et un véritable gain de productivité.

<NewsletterSignUp />


Après 2 mois d'utilisation, que penser de cette nouvelle révolution ?

GitHub Copilot : premier bilan


Avant de se lancer dans un nouveau projet, on se demande en général s'il est pertinent et apporte quelque chose à l'écosystème existant.
Dans le cadre de ce blog, les raisons de faire l'impasse semblent nombreuses :

- Les blogs techniques sont légion
- Des profils bien plus expérimentés partagent déjà du contenu
- Dégager un quelconque revenu semble peu probable
- C'est (très) chronophage

Et pourtant, si cet article est en ligne, c'est bien que les points encourageants ne manquent pas.

## Un bon exercice technique

Probablement la bonne raison la plus évidente. Créer un site en tant que développeur web est forcément une expérience intéressante.

Mais le contexte d'un blog comme celui-ci est particulièrement favorable sur deux aspects.

### Liberté de choix

Quand on travaille pour d'autres, on doit souvent composer avec des choix qui nous sont imposés. Qu'il s'agisse d'une machine de travail, d'un framework précis ou bien d'une organisation d'équipe.

Ce n'est pas nécessairement problématique, mais il est rafraîchissant mentalement d'avoir une totale liberté sur un projet personnel. Surtout dans le cadre d'un projet non lucratif, où les expérimentations sont sans conséquence.

Dans le cadre de projets comme celui-ci, j'ai pu, entre autres, me former sur [Next.js](https://nextjs.org) (qui est devenu un coup de coeur), tester [Tailwind](https://tailwindcss.com), apprendre à gérer la mise en production.

### Rapidement lancé

En créant un petit blog tout simple, très épuré, je me suis donné un objectif atteignable au résultat visible en quelques heures.

Il est plus motivant de se lancer dans ces conditions. Je trouve plus encourageant d'améliorer un site déjà en ligne plutôt que de s'embourber dans un concept complexe durant de longs mois.

<BlogImage
src="/images/les-raisons-pour-lesquelles-ce-blog-existe/motivation-curve.png"
alt="Courbe de motivation au fil du temps pour un projet"
/>

Au lancement d'une nouvelle idée, les idées fusent et la motivation atteint rapidement un pic. C'est le moment idéal pour déployer une première version, avant que l'énergie retombe brutalement.

Apprendre à encaisser les baisses de moral pour aller au bout d'une entreprise complexe est aussi un bel exercice. Mais il est possible d'éviter les vagues sur des projets de petite envergure.

## Pas cher

Proposer du contenu gratuitement, c'est plus agréable lorsque cela ne nous coûte rien de plus que du temps. Ce qui est déjà beaucoup.

Heureusement, c'est une très bonne époque pour partager des sites au contenu statique ! Les options d'hébergement gratuites ne manquent pas et sont qualitatives.

Ce blog étant basé sur **Next.js**, je me suis naturellement orienté vers [Vercel](https://vercel.com). Ce service est exemplaire : très simple à utiliser, totalement gratuit et performant. C'est le troisième site que j'héberge chez eux avec grand plaisir.

Il existe une pléthore d'alternatives que je n'ai pas encore testées. Entre autres :

- [Github Pages](https://pages.github.com)
- [Netlify](https://www.netlify.com)
- [Render](https://render.com/)

## Pour mémoriser

<Quote
content="La répétition fixe la notion."
/>

Formule répétée régulièrement par un enseignant durant mes études. Elle m'est restée en tête depuis, probablement pas un hasard.

Pour comprendre des concepts, ma méthode préférée consiste à les expliquer à d'autres. Ce travail de vulgarisation force à synthétiser pour soi-même.

Durant ce processus, j'anticipe les questions que l'on pourrait me poser. Préparer des réponses revient à se faire son propre petit examen de connaissances.

Écrire des articles de blog est une **excellente** façon de vérifier ce que l'on sait d'un sujet, et même d'en apprendre davantage.

## Partager un point de vue

Il y a cependant eu un véritable frein avant de créer ce petit site. Le **syndrome de l'imposteur**.

<BlogImage
src="/images/les-raisons-pour-lesquelles-ce-blog-existe/among-us.png" alt="Syndrome de l'imposteur"
/>

C'est un problème récurrent chez beaucoup de créateurs/créatrices de contenu. Il est aujourd'hui extrêmement simple de partager en ligne, sous de multiples formats, avec une qualité qui était auparavant réservée aux professionnels. Cette prolifération de créations provoque bien souvent de multiples remises en question.

<Quote
content="Bidule fait la même chose et c'est trop compliqué d'atteindre le même niveau"
/>

S'empêcher de faire sous prétexte que quelqu'un d'autre fait mieux, c'est dommage. Il faut bien partir de quelque part. Sinon il n'y aurait qu'un seul professionnel par métier, ce qui serait vite limité.

<Quote
content="Je n'ai pas 30 ans d'expérience dans mon domaine, je ne suis pas légitime pour en parler publiquement"
/>

Personne ne détient la vérité absolue et l'unique vision qui devrait exister. Il est bien plus intéressant de confronter des opinions de personnes aux expériences variées.

<Quote content="Pourquoi dire quelque chose que quelqu'un d'autre a probablement déjà partagé" />

Il est effectivement probable que le sujet ait déjà été abordé ailleurs. D'autant plus si on prend en compte le contenu en langue étrangère.

Il est tout de même pertinent de partager son propre point de vue. Tout simplement, car on peut aborder les choses sous un angle différent, avec une sensibilité différente.

Avez-vous déjà vécu ce moment, durant l'enfance, où une matière scolaire paraît fascinante grâce à son enseignant.e ? Où elle semble bien fade avec d'autres ? Le contenu de départ est pourtant similaire, mais la façon de le partager fait toute la différence.

## Le mot de la fin

C'est aujourd'hui un grand plaisir personnel que de partager ce premier article. J'espère qu'il vous a plu.

Si c'est le cas, n'hésitez pas à vous inscrire à ma newsletter ci-dessous !

<NewsletterSignUp />


Alors qu'il en existe une quantité astronomique sur internet, pourquoi en ajouter un autre ? Il y a de bonnes raisons.

Et non, ce n'est pas pour devenir riche.

Les raisons pour lesquelles ce blog existe


Pourtant méfiant envers les nouvelles technos qui brillent, j'ai succombé à l'appel d'[Astro](https://astro.build/).

Dur de passer à côté en surveillant l'écosystème JavaScript. Depuis son lancement, les retours élogieux se multiplient à son encontre et ses mises à jour ne cessent d'impressionner. L'outil se veut aujourd'hui être le prétendant idéal pour créer des blogs ou sites majoritairement statiques. Le nouveau Gatsby.

Ça tombe bien, j'écris sur un blog majoritairement statique. Réalisé avec [Next.js](https://nextjs.org), c'est le terrain de jeu parfait pour comparer les deux frameworks.

## Pourquoi Astro ?

Le framework fait de l'excellent travail pour [présenter ses atouts](https://docs.astro.build/en/concepts/why-astro/). Certains m'ont tapé dans l'oeil :

-   Approche zéro JavaScript par défaut, encourage la sobriété
-   Se rapproche davantage des standards du web
-   Pensé pour les blogs, intégration facilitée du MDX

Le tout enrobé de promesses pas vilaines concernant sa rapidité et le confort de développement qu'il propose. Sur le papier, tout est parfait pour créer un blog d'une fluidité sans faille.

## Anatomie d'une migration

C'est parti ! Pour initialiser un projet Astro, [rien de plus simple](https://docs.astro.build/en/install/auto/) :

```bash
pnpm create astro@latest
```

Le coeur du site est un ensemble d'articles rédigés en MDX. Astro ne gère nativement que le Markdown mais une commande de plus nous apporte le MDX :

```bash
pnpm astro add mdx
```

Il est désormais temps de profiter de la notion de [collection de contenus](https://docs.astro.build/en/guides/content-collections). Astro permet de profiter de la force de TypeScript pour les manipuler.

```typescript
import { z, defineCollection } from "astro:content";

const articlesCollection = defineCollection({
    type: "content",
    schema: z.object({
        category: z.string(),
        title: z.string(),
        description: z.string(),
        subtitle: z.string(),
        isPublished: z.boolean(),
        publishedAt: z.date(),
        updatedAt: z.date(),
    }),
});

export const collections = {
    articles: articlesCollection,
};
```

En ajoutant ce contenu dans un fichier `src/content/config.ts`, il est désormais trivial de gérer les fichiers MDX situés dans le dossier `src/content/articles`.

La page d'accueil doit afficher la liste des articles ? Rien de plus simple :

```astro
---
import ArticleItem from "@components/article/ArticleItem.astro";
import Layout from "@layouts/Layout.astro";
import { getCollection } from "astro:content";

const articles = await getCollection("articles");
---

<Layout title="Welcome to Astro.">
    <main>
        <div class="mx-auto mt-20 p-6">
            <h1 class="text-4xl text-primary-600 font-semibold">
                Dernières publications
            </h1>
            <section class="flex flex-col gap-20">
                {articles.map((article) => <ArticleItem article={article} />)}
            </section>
        </div>
    </main>
</Layout>
```

Un très bon point pour Astro.

Les collections de contenu sont simples à utiliser, disponibles nativement. Pour reproduire des fonctionnalités équivalentes dans Next.js, il faut fournir davantage d'efforts.

### Et si je veux un composant dynamique ?

C'était un point de questionnement au début de cette transition. En bas de chaque article se trouve un composant pour s'inscrire à la Newsletter.

<NewsletterSignUp />
<Spacer size={8} />

Rien de très compliqué ici. Le composant se contente d'envoyer l'email vers une API qui communique en retour le succès (ou l'échec) de l'opération.

Dans Next.js, un simple fichier `pages/api/newsletter.ts` permet de créer la partie API et React se charge de la réactivité du composant.

Pour l'API, Astro propose un mécanisme similaire avec les [server endpoints](https://docs.astro.build/en/guides/endpoints/#server-endpoints-api-routes). J'ai d'ailleurs pu reprendre la quasi intégralité du code de mon `newsletter.ts`.

Mais cela demande d'activer le mode [SSR](https://docs.astro.build/en/guides/server-side-rendering/). Par défaut, Astro fonctionne uniquement en SSG.

Là aussi, le framework propose une mise en place rapide en ajoutant une ligne dans le fichier de config :

```js
export default defineConfig({
    ...
    output: 'hybrid'
    ...
});
```

Avec **hybrid**, Astro part du principe que mon projet fonctionne encore majoritairement en SSG. Il faut préciser en haut d'un fichier si ce fonctionnement n'est pas souhaité :

```js
export const prerender = false;
...
```

Si le projet exploitait majoritairement le SSR, il aurait fallu utiliser l'option **server**.

À partir de là, il faut ajouter un [adapter](https://docs.astro.build/en/guides/server-side-rendering/) pour faire tourner le code sur un serveur. Le projet étant hébergé chez Vercel, ça ne demande qu'une petite commande :

```bash
pnpm astro add vercel
```

Et voilà ! La partie API est en place.

### Et la partie réactive ?

C'est ici qu'Astro met en avant un de ses arguments de vente. L'intégration à la carte de [frameworks UI](https://docs.astro.build/en/guides/framework-components/).

Par défaut, Astro vise à créer un site comportant un minimum de JavaScript. Mais il souhaite nous laisser la liberté d'utiliser nos frameworks préférés pour certaines parties de nos projets. En une commande, on peut ajouter React, Vue, Svelte, Solid, ou n'importe quel framework qui possède une intégration Astro.

À partir de là, il est possible de créer un composant `Newsletter.tsx` et de l'intégrer dans une page `index.astro`. Techniquement, il est même envisageable d'utiliser plusieurs frameworks UI au sein d'un même projet.

```jsx
---
// Exemple officiel: Mélanger plusieurs frameworks sur la même page
import MyReactComponent from '../components/MyReactComponent.jsx';
import MySvelteComponent from '../components/MySvelteComponent.svelte';
import MyVueComponent from '../components/MyVueComponent.vue';
---
<div>
  <MySvelteComponent />
  <MyReactComponent />
  <MyVueComponent />
</div>
```

Mais je n'en vois pas l'intérêt. Combiner les frameworks me semble un bon moyen de rendre le code confus. En utiliser un seul, par contre, présente de sérieux avantages.

Ce n'est malgré tout pas l'option que j'ai choisie. Quitte à faire une refonte totale sous Astro, autant profiter de son faible coût JavaScript jusqu'au bout. En plus, le composant Newsletter n'est pas bien complexe.

```astro
---
// Exemple officiel pour intégrer un script dans un composant Astro
---
<h1>Coucou !</h1>

<script>
  console.log('Coucou la console !');
</script>
```

En rajoutant une balise `<script>` en bas d'un composant Astro, on peut tout à faire écrire du JavaScript "à l'ancienne". Et donc utiliser un Event Listener sur le formulaire et appeler l'API avec `fetch`. Quelques lignes à peine qui évitent de surcharger tout le site d'un framework UI.

Il faut reconnaître que l'opération reste moins agréable que de manipuler un fichier TSX. Rien que l'utilisation d'un useState simplifierait la manoeuvre. Mais ça reste un coût bien faible pour s'épargner le poids d'un framework entier.

### Et ensuite ?

Derrière, le travail consiste à recoder certains composants .tsx pour en faire des .astro. Une manoeuvre qui s'est bien déroulée.

Concernant le SEO, un projet [astro-seo](https://github.com/jonasmerlin/astro-seo) existe pour apporter un équivalent à [next-seo](https://github.com/garmeeh/next-seo).

Pour le sitemap, c'est là aussi [élémentaire](https://docs.astro.build/en/guides/integrations-guide/sitemap/) et nativement intégré.

Et pour déployer tout ça, les options sont nombreuses et [bien documentées](https://docs.astro.build/en/guides/deploy/).

### MAIS

Malgré toutes ces étapes réalisées _relativement_ rapidement, malgré les avantages réels du framework, j'ai pris la décision de ne pas utiliser cette refonte **pour le moment** et de rester sur Next.js.

## Pourtant, Astro c'est bien

Pas de doute, le framework est déjà une alternative intéressante pour certains cas d'usage.

Le focus mis sur la simplicité et la gestion des collections de contenu le distingue dans ce secteur bondé d'options. Malgré cette volonté quasi minimaliste, Astro se veut de plus en plus complet.

J'ai débuté l'écriture de cet article en ayant des points de friction de notés. Certains n'existent déjà plus, corrigés par la dernière MAJ. Le projet est vivant, ce qu'il accomplit en ayant à peine [3 ans d'existence](https://twitter.com/astrodotbuild/status/1768646279230279849) est conséquent.

En prime, voici quelques points positifs non évoqués :

-   La documentation est claire et riche
-   Intègre nativement [Shiki](https://shiki.style/) qui est un plaisir à utiliser
-   La syntaxe proche de Vue me parle totalement

## Mais Astro ne me convient pas totalement

Impossible de trouver un outil qui coche absolument toutes les cases. Dans le cas d'Astro, voici celles qui ne sont pas cochées dans mon cas.

### Combiner avec un framework UI : oui mais non

Déjà évoqué brièvement plus haut, je ne suis pas convaincu par la possibilité d'intégrer un framework UI au sein d'un projet Astro.

C'est pourtant une force indéniable du projet et un argument qu'ils mettent grandement en avant. À raison, c'est un point de différenciation majeur et une bonne façon d'attirer un public réticent à l'idée de quitter sa zone de confort.

<BlogImage
    src="/images/passer-de-nextjs-a-astro/astro_ui_frameworks.png"
    alt="Compatibilité d'Astro avec différents frameworks UI"
    subtitle="Compatibilité d'Astro avec différents frameworks UI"
    size="small"
/>

Mais ça ne correspond pas à mon approche. Quitte à utiliser un outil comme Astro, quitte à viser une sobriété, autant aller au bout de l'idée. Naviguer dans un projet qui combine différentes façons de créer des composants n'est pas instinctif pour moi. Je préfère avoir l'esprit uniquement focalisé sur du code React ou Vue, par exemple.

### Copilot ne copilote plus très bien

[J'apprécie l'apport de Github Copilot](/article/github-copilot-apres-2-mois).

L'outil m'aide durant mon processus de développement et répond, souvent avec justesse, à mes questions.

Astro est encore jeune et ne cesse d'évoluer, Copilot ne peut pas proposer de réponse pertinente à son sujet. Il peut encore m'assister durant l'écriture en anticipant ce que je souhaite ajouter, mais il est à oublier en dehors de cet usage.

Cependant, ce n'est pas un défaut majeur et c'est un souci inhérent à tout projet récent.

### Quelques points de friction

-   Le concept de [View Transitions](https://docs.astro.build/en/guides/view-transitions/) est intéressant et simple à mettre en place. Je n'ai juste pas accroché, probablement par manque de temps pour m'y habituer.
-   C'était ma deuxième tentative d'utilisation d'Astro pour un projet. Les deux fois, TypeScript n'a pas été coopératif. Pour une raison que j'ignore, alors que cela ne m'arrive pas sur d'autres projets (Next, Nuxt, React, Angular, ...), les nouveaux fichiers .astro ne sont pas pris en compte après leur création. L'autocomplétion ne se fait pas si je souhaite les importer ailleurs, jusqu'à ce que je redémarre le serveur TypeScript. Une manipulation à faire à chaque nouveau fichier.
-   Astro évolue vite. Très vite. C'est à la fois excitant et exigeant si l'on souhaite se tenir au courant des nouveautés et profiter pleinement du framework.
-   Importer des SVG comme composants n'est [pas encore](https://github.com/withastro/roadmap/issues/699) intégré nativement.
-   La commande [preview](https://docs.astro.build/en/reference/cli-reference/#astro-preview) ne fonctionne pas en cas d'utilisation de l'adaptateur Vercel

Vu le rythme d'évolution d'Astro, il est probable que les points évoqués ci-dessus soient obsolètes rapidement.

## Bilan de l'aventure

Cette expérience m'a permis de découvrir un framework prometteur, déjà prêt à répondre à divers usages. Ce n'est pas un hasard s'il se fait une place en production, chez [Porsche](https://twitter.com/youyuxi/status/1768601792647192893) par exemple.

Mais ça m'a surtout permis de réaliser l'importance de deux apprentissages récents.

### Penser à l'utilisateur en priorité

Faire une refonte, c'est enrichissant. Le travail effectué n'est pas perdu et je ne regrette pas d'y avoir consacré du temps.

Mais ce temps aurait pu être dédié à améliorer l'expérience utilisateur.

<BlogImage
    src="/images/passer-de-nextjs-a-astro/current_blog_perfs.png"
    alt="Performances actuelle du blog, sur mobile, selon PageSpeed"
    subtitle="Performances actuelle du blog, sur mobile, selon PageSpeed"
    size="small"
/>

La version actuelle du blog est déjà performante et répond à mes attentes. Peut-être que la migration vers Astro aurait pu pousser le curseur encore plus loin. Mais l'impact auprès du public aurait été quasi nul.

Au lieu de chercher à améliorer ce qui est bon, j'aurai pu rajouter des fonctionnalités appréciables. Ce ne sont pas les idées qui manquent.

Il ne faut pas perdre de vue qu'un.e internaute ne regarde pas si notre code est rédigé avec Astro ou Next.js. Seul le résultat l'impacte.

### Choose whats sparks joy

J'ai récemment découvert le formidable travail de Takuya Matsuyama. Sa [chaîne YouTube](https://www.youtube.com/@devaslife) est une source d'inspiration. Au-delà de l'aspect technique, je me sens en phase avec sa vision.

Dans un [article récent](https://www.devas.life/tech-choices-for-continuing-indie-development-for-over-7-years/), il fait un bilan de 7 années passées à développer un logiciel en indépendant. Un excellent article, dont certaines parties résonnent encore.

Entre autre, sa section _When in doubt, choose what "sparks joy"_.

Il y explique que bien souvent, de multiples options sont valides pour répondre à un besoin. Des nuances existent mais fondamentalement, chaque chemin permet d'arriver au résultat souhaité.

Dans ce cas, comment choisir entre A et B ? Entre Astro et Next.js ?

Takuya propose d'opter pour ce qui amène de la **joie**. Ce qui sonne juste à nos yeux. L'option satisfaisante, l'option qui nous donne envie de continuer. L'impact de la motivation sera plus décisif qu'une micro nuance entre A et B.

C'est exactement ce qui explique ma décision de rester sur Next.js. Astro coche beaucoup de cases et, objectivement, je trouve l'outil adapté à mon besoin. Mais je ne prends pas autant de plaisir à l'utiliser, là où je me sens motivé en développant avec Next ou même Nuxt.

Pour continuer d'améliorer ce blog, je choisis ce qui m'amène du plaisir.

<NewsletterSignUp />


Étapes pour convertir un blog Next.js vers Astro et retour d'expérience

Et pourquoi ce blog reste sur Next.js

Passer de Next.js à Astro


Il est désormais bien visible en haut de tous les articles.

Ce badge n'est pas un symbole guerrier contre l'IA mais une volonté de clarifier ses usages et ses limites.

## Quelle est sa signification ?

Son texte est plutôt explicite. S'il est intégré dans un article, je **m'engage** à l'avoir rédigé manuellement. Sans avoir demandé à une IA (ChatGPT ou concurrents) de générer des pans entiers de texte ou de donner une structure détaillée qu'il suffirait de suivre derrière.

<BlogImage
    src="/images/pourquoi-badge-fait-main/no_to_chatgpt.png"
    alt="Refus d'utiliser ChatGPT pour générer du contenu"
    size="small"
/>

Cependant, certains usages sont tolérés :

-   Relecture orthographique / grammaticale d'un texte
-   Recherche de synonymes
-   Améliorations SEO

Dans ces cas, l'IA remplace des outils déjà existants et peut se montrer plus efficace à un tarif moindre.

Elle est utilisée avec un rôle d'assistance et non de génération. Le sujet est aussi abordé dans [cet article concernant GitHub Copilot](/article/github-copilot-apres-2-mois).

## Dans quel but ?

### Un choix éthique

L'IA s'est démocratisée à une vitesse hallucinante et ne semble pas ralentir. Il est probable que son usage continue de progresser et que ces outils soient de plus en plus intégrés à notre quotidien.

<BlogImage
    src="/images/pourquoi-badge-fait-main/statista_chatgpt_adoption.jpeg"
    alt="Adoption de ChatGPT, statistiques Statista"
    subtitle="Statistiques Statista - 25/01/2023"
/>

Tenter d'interdire cette technologie paraît contreproductif. Mais il est souhaitable de pouvoir distinguer le contenu généré par IA de celui créé par des humains. Entre autres, afin d'éviter la [désinformation](https://www.francetvinfo.fr/internet/intelligence-artificielle/intelligence-artificielle-openai-annonce-des-mesures-pour-eviter-que-ses-ia-soient-utilisees-a-des-fins-de-desinformation-politique_6306804.html).

En attendant que d'éventuelles mesures soient mises en place, intégrer ce badge est ma façon de donner mon positionnement sur le sujet et répondre à cette problématique. C'est léger, mais c'est mieux que rien.

### Une forme de respect

Je fais des recherches en ligne depuis des années et n'ai jamais trouvé la tâche aussi laborieuse qu'aujourd'hui.

Le besoin de plaire aux moteurs de recherche (particulièrement Google) a déjà massivement contribué à créer un [web qui priorise le SEO](https://www.clubic.com/actualite-515785-non-ce-n-est-pas-qu-une-impression-la-pertinence-des-resultats-google-s-est-bel-et-bien-empiree-ces-derniers-temps.html) au confort des utilisateur.rice.s. Pour trouver une petite information, il est devenu courant de devoir parcourir un article interminable et creux avant de tomber sur ce qui était recherché.

<BlogImage
    src="/images/pourquoi-badge-fait-main/carol_information_planquee.png"
    alt="Un grand article pour trouver une petite info"
    size="large"
/>

L'arrivée de l'IA empire cette situation. Il n'a jamais été aussi simple de créer des articles génériques, en grande quantité, en empilant du vide autour d'une petite information. Sans parler du [vol de contenu](https://www.frandroid.com/culture-tech/intelligence-artificielle/1905699_openai-chatgpt-admet-quil-faut-voler-du-contenu-pour-creer-une-ia) qui nous amène à voir les 10 premiers résultats d'une recherche proposer des textes étrangement similaires et à la pertinence douteuse.

En plaçant ce badge en haut de page, j'indique une volonté d'écrire un contenu authentique. Un contenu qui ne copie-colle pas ce qui est disponible ailleurs. Un contenu qui respecte le temps des personnes qui veulent en profiter.

## C'est un gage de qualité ?

Pas forcément. On peut écrire un texte manuellement, de la façon la plus sincère possible, sans qu'il ne soit d'une qualité remarquable.

Mais c'est un gage d'authenticité et il est plus probable de voir quelque chose d'original sous ce badge que sur un site qui publie des articles générés par IA.

## Quelle est sa validité juridique ?

Il n'en a aucune. Personne ne vérifie ce que j'affirme et je pourrai tout à faire mentir à ce sujet.

Mais mon contenu imparfait devrait parler de lui-même.

## Puis-je utiliser le badge sur mon site ?

J'en serai ravi ! Il faudrait cependant me citer quelque part. Avec un lien vers cet article d'associé au badge par exemple.

⚠️ Il ne faut pas le présenter comme un label certifiant. Comme dit juste au-dessus, il n'a aucune validité juridique et n'engage que la parole de la personne qui s'en sert.

Si la demande se fait fréquente, je pourrai proposer un petit kit pour l'intégrer facilement sur des sites.

## J'ai des questions !

Pas de souci, je suis joignable par mail sur [pierre@devzen.fr](mailto:pierre@devzen.fr).


Les raisons pour lesquelles il trône en haut de tous les articles.

La distinction devient importante.

Pourquoi un badge "100% fait main" ?


À la question "Faut-il tester son code ?", beaucoup de devs auront tendance à répondre "**Bien sûr !**".

À la question "Testes-tu ton code ?", la tendance risque de s'inverser.

Malgré l'impact positif de la pratique, elle est difficilement intégrée dans une routine de développement. D'autant plus si l'on parle de projets réalisés en solitaire ou de petite envergure.

Quand j'étais étudiant, j'esquivais au maximum cette étape. Quelques années plus tard, j'écris cet article. Qu'est-ce qui a changé ?

## Tester c'est pénible

Cet aspect reste présent. Pas la peine de faire l'autruche, autant accepter la réalité. La pénibilité variera selon les goûts, mais on retrouve souvent les reproches suivants :

- Écrire des tests, c'est du temps non consacré aux nouvelles features
- C'est souvent répétitif et peu excitant
- Les résultats ne sont pas visibles à court terme

Ces aspects désagréables sont accentués sur des projets de petite envergure. Les bénéfices des tests ne sont pas flagrants quand on peut facilement vérifier la validité du code manuellement.

Ce qui rend l'apprentissage peu évident. Si l'on découvre les tests sur de minuscules projets, le temps consacré à les écrire paraît démesuré par rapport au gain final. Les étudiants rechignent généralement à les mettre en place, ce qui se comprend.

## C'est pourtant crucial

Pourtant, les avantages sont présents. Plus le projet prend de l'envergure, plus on se félicite d'avoir réalisé ces tests.

### Un gain de temps phénoménal

C'est le bénéfice le plus évident. Vérifier manuellement une fonctionnalité ou deux, c'est rapide. Mais lorsque celles-ci se comptent en dizaines, cela devient un fardeau.

<BlogImage
src="/images/tester-son-code-une-indispensable-perte-de-temps/exemple-calcul-temps-1.png"
alt="Calcul de rentabilité d'un test - cas simple"
/>

Imaginons le cas d'un petit projet. Mettre en place des tests automatisés a demandé par exemple 2 heures. En visant large, en supposant qu’il faut une heure pour initialiser les tests et une autre pour ajouter quelques cas.

Si un parcours complet de l’application développée demande 30 secondes, alors il faudra 240 parcours pour "rentabiliser" l’écriture des tests.

Ça paraît beaucoup, mais je te propose de compter le nombre de fois que tu testes manuellement ton projet durant une session de développement. Et si possible, d’enregistrer le temps consacré.

<BlogImage
src="/images/tester-son-code-une-indispensable-perte-de-temps/exemple-calcul-temps-2.png"
alt="Calcul de rentabilité d'un test - cas moyen"
/>

Prenons désormais un projet plus ambitieux. Il faut toujours une heure pour initialiser le processus de tests et imaginons qu'il a fallu 9 heures de plus pour écrire différents cas complexes. Soit 10 heures au total.

Cette fois-ci, le parcours complet de l'application prend 5 minutes. Et 3 personnes travaillent sur le projet. En seulement 120 parcours, les tests sont rentabilisés. À peine 40 parcours par personne.

### Une tâche répétitive

Oui, c'est aussi une qualité.

Parfois, écrire des tests se révèle complexe et exigeant. Mais bien souvent, le code à écrire est accessible et se base sur des tests déjà réalisés pour d'autres projets ou d'autres sections de celui en cours.

Cela rend l'écriture peu palpitante, mais on peut le voir comme quelque chose de bénéfique. L'énergie fluctue durant une journée et il est complexe de garder l'esprit affûté pour des tâches exigeantes sur de longues plages horaires.

Pouvoir profiter d'un coup de mou pour effectuer des tâches répétitives comme l'écriture de tests est un avantage sous estimé.

## Quelle méthodologie adopter ?

Ça y est, tu es convaincu. Tu dois absolument tester ton code désormais !

Mais comment s'y prendre ?

De multiples méthodologies existent, toutes valables selon les circonstances. Je vais me concentrer sur la plus réputée puis aborder ma vision actuelle du sujet.

### Le TDD

Le fameux [Test Driven Development](https://fr.wikipedia.org/wiki/Test_driven_development). La méthode est assez simple à comprendre et se base sur ces 3 principes :

- Il faut d'abord écrire un test qui échoue avant d'écrire du code "de production"
- Il ne faut pas écrire un autre test tant que le précédent est en échec
- Il faut écrire uniquement le code nécessaire pour passer le test précédemment en échec

<BlogImage
src="/images/tester-son-code-une-indispensable-perte-de-temps/etapes-du-tdd.png"
alt="Les différentes étapes du TDD"
/>

C'est une vision assez rigoureuse du développement. Penser d'abord au test aide à focaliser son attention sur le minimum nécessaire pour le valider. On évite de s'éparpiller.

Cela aide aussi considérablement à écrire un code bref et efficace. On code, on lance le test, on répète l'opération jusqu'à ce qu'il soit validé.

Suivre la méthodologie TDD, c'est aussi éviter d'écrire des tests **pour** valider le code écrit au préalable. Des tests potentiellement biaisés ou qui valident un code fonctionnel, mais bien moins performant qu'il ne pourrait être.

### Mon approche

Ayant suivi la méthodologie TDD pendant un temps, j'ai apprécié ses avantages.

Cependant, j'ai tendance à penser que cette méthode fonctionne dans un monde **utopique**. Dans un monde où il n'y a jamais de délais urgents à tenir et où l'on sait parfaitement où l'on va à chaque instant.

Sur le papier, je n'ai pas de reproches particuliers à adresser au TDD. C'est une méthode théoriquement solide et efficace. Mais dans les faits, je préfère être plus flexible durant mes séances de développement.

Mes principes actuels ressemblent à ceci :

- Tester 100% de son code est souvent inadapté
- Lorsque je sais exactement où je vais, appliquer le TDD est envisageable
- Écrire des tests après coup, c'est mieux que de ne pas en écrire
- Les fonctionnalités majeures d'un projet doivent être testées
- L'objectif reste l'efficacité. Un test doit être **clair** et **simple**

Ces règles fonctionnent bien dans mon cas et sur la plupart des projets sur lesquels j'ai pu travailler. Elles me permettent de trouver un équilibre entre créativité et rigueur, entre rapidité et fiabilité.

## Conclusion

C'est en suivant cette approche que j'ai réalisé les tests de [Juju & Caillou](https://jujuetcaillou.fr), un site de recettes de cuisine développé avec [API Platform](https://api-platform.com) et [Next.js](https://nextjs.org). C'est un projet codé 100% en solitaire, mais sur lequel j'exécute 184 assertions avant de déployer en prod.

<BlogImage
src="/images/tester-son-code-une-indispensable-perte-de-temps/tests-jc.png"
alt="Tests fonctionnels sur Juju & Caillou"
subtitle="Toujours satisfaisant de voir ceci"
size="extra-small"
/>

Les écrire n'a pas demandé un temps considérable. Mais cela me permet de mettre à jour le projet sans encombre depuis 15 mois. Je suis plus serein en sachant que les éventuels effets de bord (en montant de version un package par exemple) seront signalés par les tests. Plus d'une fois, cela m'a évité de déployer un code devenu non fonctionnel. Tout en m'évitant de longues chasses à l'origine des bugs.

En général, il vaut mieux prévenir que guérir. On y gagne du temps et de la tranquillité d'esprit.

Qu'on travaille en solitaire ou en équipe, tester son code c'est assurer un futur plus serein.

<NewsletterSignUp />


Pourquoi se l'infliger même en tant que solo dev ?

CSS

Comment Tailwind CSS m'est devenu indispensable

Frontend

Passer de Next.js à Astro

Full Stack

Tester son code : une indispensable perte de temps

IA

GitHub Copilot : premier bilan

Pourquoi un badge "100% fait main" ?

Motivation

Les raisons pour lesquelles ce blog existe