Vous avez probablement déjà vécu la scène : un pipeline CI qui tourne deux minutes uniquement pour passer les règles ESLint et le reformatage Prettier, sur un projet pourtant de taille modeste. En 2026, cela n'est plus une fatalité. Biome ESLint Prettier 2026 — voilà l'équation que toute équipe frontend sérieuse doit maintenant connaître. Biome est un outil unique, écrit en Rust, qui remplace simultanément votre linter et votre formateur en offrant des performances jusqu'à 25 fois supérieures sur des codebases réelles.

Chez ConsilioWEB, nous avons intégré Biome sur plusieurs projets Next.js et Astro que nous développons pour des PME françaises. Le gain de temps en CI — et donc en facture cloud — est immédiat, mesurable, et sans régression qualité. Cet article vous explique pourquoi le duo ESLint + Prettier montre ses limites en 2026, comment fonctionne l'architecture interne de Biome, comment migrer proprement, et dans quels cas il vaut mieux encore patienter.

Nous couvrirons : l'architecture Rust et le parser unique, les benchmarks réels, la migration pas-à-pas, la configuration pour Next.js / Astro / SvelteKit, l'intégration GitHub Actions et les limites actuelles de l'écosystème.

---

Le problème ESLint + Prettier en 2026

ESLint et Prettier sont deux outils nés à des époques différentes, pensés pour des problèmes différents, et qui coexistent dans votre `package.json` depuis des années avec un contrat fragile : `eslint-config-prettier` pour désactiver les règles de formatage d'ESLint qui entrent en conflit avec Prettier, `prettier-plugin-*` pour chaque syntaxe supplémentaire, et une configuration qui enfle dès que vous ajoutez TypeScript, Tailwind, ou des règles d'accessibilité.

Les frictions au quotidien

En 2026, plusieurs points de friction sont devenus systématiques dans les projets JS/TS modernes :

Deux configs, deux outils, deux AST : ESLint parse votre code une première fois, Prettier le parse une deuxième fois. Zéro mutualisation.
Conflits de règles difficiles à déboguer : les équipes perdent du temps à comprendre pourquoi ESLint se plaint après le passage de Prettier ou vice versa.
Performances dégradées sur les grands monorepos : sur un projet de 800 fichiers TypeScript, ESLint seul peut dépasser 40 secondes en mode `--cache` froid.
Flatconfig ESLint v9 : migration complexe : la migration vers le nouveau format `eslint.config.js` a généré une dette technique considérable dans les équipes qui n'ont pas suivi le rythme.
Plugins non maintenus : certains plugins ESLint populaires n'ont pas été mis à jour pour le flat config, créant des dépendances bloquées.

Le coût réel pour une PME

Ce n'est pas seulement un problème de DX (developer experience). Chaque minute de CI représente un coût. Sur GitHub Actions au tarif standard, 2 minutes de lint sur chaque PR sur une base de 50 PR/mois représente environ 100 minutes de facturation mensuelle. Multipliez par plusieurs projets, plusieurs équipes, et la note devient tangible. Sans parler du temps de feedback allongé pour les développeurs.

---

Biome : architecture Rust et parser unique

Biome (anciennement Rome Tools, refondé en 2023 sous gouvernance communautaire) est construit sur un principe radicalement différent : un seul parser pour tout.

Le parser unifié comme avantage structurel

Là où ESLint et Prettier maintiennent chacun leur propre représentation de l'AST (Abstract Syntax Tree), Biome construit un seul arbre syntaxique qui sert à la fois au linting et au formatage. Ce n'est pas un détail d'implémentation — c'est le cœur de la différence de performance et de cohérence.

Concrètement :

Votre fichier `.tsx` est parsé une seule fois
L'arbre produit est utilisé pour détecter les erreurs de style ET les problèmes de qualité de code
Le formateur écrit directement depuis cet arbre, sans re-parse

Biome supporte nativement JavaScript, TypeScript, JSX, TSX, JSON, JSONC, CSS (depuis Biome 1.6), et GraphQL (depuis 1.9). L'implémentation en Rust garantit une gestion mémoire sans garbage collector et un parallélisme natif par thread de fichier.

Pourquoi Rust change la donne

Rust n'est pas choisi par hasard. Le compilateur Rust force la sécurité mémoire au moment de la compilation, ce qui élimine toute une classe de bugs présents dans les outils Node.js (fuites mémoire, race conditions dans les workers). Pour Biome, cela signifie :

Multi-threading réel : Biome traite les fichiers en parallèle sur tous les cœurs disponibles, sans le GIL de Node.js
Démarrage quasi instantané : pas de JIT, pas de warm-up V8, l'exécutable est compilé natif
Binaire unique : pas de `node_modules` à installer pour l'outil lui-même, Biome se distribue comme un binaire ou via `@biomejs/biome` avec un binaire pré-compilé pour votre plateforme

---

Benchmarks réels : 10x à 25x plus rapide

Les chiffres mis en avant dans la communication de Biome ne sont pas du marketing. Voici des mesures reproduites par la communauté et documentées dans les issues GitHub du projet.

Comparaison sur des projets réels

| Projet | Fichiers TS/JS | ESLint + Prettier | Biome | Gain | |--------|---------------|-------------------|-------|------| | Monorepo 400 fichiers | 400 | 38s | 2.1s | ×18 | | App Next.js 14 standard | 120 | 14s | 0.9s | ×15 | | Grande lib utilitaire | 800 | 61s | 3.8s | ×16 | | Petit projet SvelteKit | 45 | 6s | 0.4s | ×15 |

*Sources : benchmarks publiés sur le dépôt officiel Biome et reproductions communautaires (2024-2025)*

Ces chiffres correspondent à une première exécution sans cache. Avec le cache de Biome activé (différentiel basé sur les hashes de fichiers), les exécutions suivantes tombent sous la seconde même sur les grands projets.

Le cas du formatage seul

Sur le formatage pur, Biome est mesuré entre 10x et 25x plus rapide que Prettier selon la taille des fichiers et le nombre de cœurs disponibles. Prettier étant mono-threadé dans sa version standard, l'écart se creuse linéairement avec la taille du projet.

Ce que cela change en pratique

Sur un projet Next.js typique d'une PME, passer de 14 secondes à moins d'une seconde signifie que le lint peut être lancé en `pre-commit` hook sans friction perçue par le développeur. Ce n'était pas réaliste avec ESLint + Prettier sur des fichiers volumineux.

---

Migration ESLint + Prettier vers Biome pas-à-pas

La migration est plus simple qu'on ne le craint, surtout si votre config ESLint n'est pas trop complexe. Voici la procédure recommandée en 2026.

Étape 1 : Installer Biome

```bash npm install --save-dev --save-exact @biomejs/biome # ou avec pnpm pnpm add -D --save-exact @biomejs/biome ```

L'option `--save-exact` est recommandée par l'équipe Biome car le formateur peut produire des sorties légèrement différentes d'une version à l'autre (comme Prettier).

Étape 2 : Initialiser la configuration

```bash npx @biomejs/biome init ```

Cette commande crée un fichier `biome.json` minimal. Biome propose aussi un outil de migration automatique depuis votre config ESLint :

```bash npx @biomejs/biome migrate eslint --write npx @biomejs/biome migrate prettier --write ```

Ces commandes lisent respectivement `.eslintrc.*` (ou `eslint.config.*`) et `.prettierrc.*` et tentent de transposer les règles dans `biome.json`. La couverture de migration est d'environ 80-90% des règles ESLint courantes — les règles sans équivalent sont listées dans le rapport de migration.

Étape 3 : Auditer le rapport de migration

La commande de migration produit un rapport clair :

``` ✓ Migrated 42 ESLint rules ⚠ 3 rules have no Biome equivalent: import/no-cycle, unicorn/no-for-loop, jsx-a11y/anchor-ambiguous-text ✗ 1 plugin not supported: eslint-plugin-graphql ```

Pour chaque règle sans équivalent, vous avez trois options :

Vérifier si Biome a une règle similaire sous un nom différent (la doc liste les correspondances)
Accepter de perdre cette règle (souvent acceptable pour des règles cosmétiques)
Conserver ESLint en parallèle uniquement pour ces règles spécifiques (approche hybride)

Étape 4 : Formater la codebase existante

```bash npx @biomejs/biome format --write . ```

Attendez-vous à un diff volumineux si vous passez de Prettier à Biome — les deux formateurs ne produisent pas exactement la même sortie. Commitez ce changement seul, dans un commit dédié intitulé clairement `chore: format with Biome`.

Étape 5 : Remplacer les scripts package.json

```json { "scripts": { "lint": "biome lint .", "format": "biome format --write .", "check": "biome check --write ." } } ```

La commande `check` est la plus utile en pratique : elle lance lint et format en une seule passe.

Étape 6 : Supprimer les dépendances obsolètes

```bash npm uninstall eslint prettier eslint-config-prettier eslint-plugin-prettier @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint-config-next ```

Attention : `eslint-config-next` configure aussi des règles React spécifiques. Vérifiez que Biome couvre bien vos règles React avant de désinstaller.

---

Configuration recommandée pour Next.js / Astro / SvelteKit

Next.js avec TypeScript

```json { "$schema": "https://biomejs.dev/schemas/1.9.0/schema.json", "organizeImports": { "enabled": true }, "linter": { "enabled": true, "rules": { "recommended": true, "correctness": { "noUnusedImports": "error", "useExhaustiveDependencies": "warn" }, "suspicious": { "noConsoleLog": "warn" }, "accessibility": { "noBlankTarget": "error", "useAltText": "error" } } }, "formatter": { "enabled": true, "indentStyle": "space", "indentWidth": 2, "lineWidth": 100 }, "javascript": { "formatter": { "quoteStyle": "double", "trailingCommas": "all", "semicolons": "always" } }, "files": { "ignore": [".next", "node_modules", "public", "*.min.js"] } } ```

Pour Next.js, notez que Biome ne remplace pas encore toutes les règles de `eslint-config-next` (notamment les règles Core Web Vitals et les warnings spécifiques à l'App Router). L'équipe Biome travaille sur un preset officiel Next.js — en attendant, une approche hybride est possible.

Astro

Biome supporte les fichiers `.astro` via un plugin de la communauté depuis la version 1.8. Ajoutez dans `biome.json` :

```json { "files": { "include": ["src/**/*.{js,ts,jsx,tsx,astro}"] } } ```

SvelteKit

Le support Svelte est encore en développement actif dans Biome. En juin 2026, les fichiers `.svelte` ne sont pas encore formatés nativement — Biome gère le JS/TS dans les blocs `<script>` via un plugin communautaire. Consultez le tracker sur GitHub avant de migrer un projet SvelteKit entièrement.

---

Intégration CI/CD avec GitHub Actions

L'un des plus grands gains concrets de Biome se réalise en CI. Voici une configuration GitHub Actions optimisée.

Workflow de base

```yaml name: Code Quality

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

jobs: biome: name: Lint & Format runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4

- name: Setup Biome uses: biomejs/setup-biome@v2 with: version: latest

- name: Run Biome check run: biome ci . ```

La commande `biome ci` est distincte de `biome check` : elle ne modifie aucun fichier mais retourne un code d'erreur non-zéro si des problèmes sont détectés, ce qui fait échouer le job proprement.

Avantage sur le temps de CI

L'action officielle `biomejs/setup-biome` télécharge uniquement le binaire pré-compilé (environ 8 Mo), sans installer de node_modules. Le job complet — checkout + setup + lint + format de 200 fichiers — tourne en moins de 30 secondes sur `ubuntu-latest`.

Par comparaison, un job ESLint + Prettier classique avec `npm ci` puis les commandes lint/format prenait typiquement 2 à 4 minutes sur le même runner pour la même codebase.

Intégration avec les PR Checks

Biome produit des annotations GitHub directement sur les lignes de code concernées dans les Pull Requests, sans plugin supplémentaire. L'output JSON de Biome est compatible avec le format attendu par l'action de reporting GitHub.

```yaml - name: Run Biome check run: biome ci --reporter=github . ```

Le flag `--reporter=github` active les annotations inline dans l'interface PR, exactement comme le faisait `eslint-formatter-github`.

Cache des résultats

Biome maintient un cache local dans `.biome/`. Pour accélérer encore les runs CI :

```yaml - name: Cache Biome uses: actions/cache@v4 with: path: .biome key: biome-${{ hashFiles('biome.json') }}-${{ hashFiles('/*.ts', '/*.tsx') }} ```

Avec le cache CI activé, les runs suivants n'analysent que les fichiers modifiés depuis le dernier run réussi.

---

Limites actuelles : écosystème plugins encore jeune

Biome n'est pas une solution parfaite pour tous les projets. Voici un état honnête des limites en juin 2026.

Pas de système de plugins tiers (encore)

C'est la limite la plus structurante. ESLint dispose d'un écosystème de centaines de plugins (`eslint-plugin-unicorn`, `eslint-plugin-sonarjs`, `eslint-plugin-import`, etc.). Biome ne supporte pas encore les plugins tiers écrits par la communauté — toutes les règles doivent être intégrées dans le core.

L'équipe Biome a annoncé un système de plugins basé sur GritQL (un langage de requête de code) prévu pour 2026, mais au moment de la rédaction, ce système est encore en phase expérimentale.

Règles manquantes par rapport à ESLint

Malgré plus de 200 règles intégrées, certaines règles populaires n'ont pas encore d'équivalent Biome :

`import/no-cycle` (détection de dépendances circulaires)
`eslint-plugin-testing-library` (règles spécifiques aux tests)
`eslint-plugin-storybook`
Règles `jsx-a11y` avancées (couverture partielle)

Pour les projets avec de fortes exigences d'accessibilité ou de couverture de tests, une approche hybride peut être nécessaire.

Support CSS limité

Biome supporte le lint CSS depuis la version 1.6, mais la couverture des règles reste inférieure à Stylelint. Si votre projet repose sur des règles Stylelint complexes (ordre des propriétés, conventions de nommage BEM, etc.), Biome ne peut pas encore remplacer Stylelint.

Absence de règles custom en JS/TS

Contrairement à ESLint où vous pouvez écrire vos propres règles en JavaScript, Biome ne permet pas encore d'écrire des règles custom sans contribuer au core (en Rust). C'est un frein pour les grandes équipes avec des conventions internes spécifiques.

Quand maintenir ESLint + Prettier ?

Si vous utilisez `eslint-plugin-import/no-cycle` sur un grand monorepo
Si vous avez des règles custom ESLint écrites en interne
Si votre framework impose ESLint (Nuxt 4, par exemple, embarque sa propre config ESLint)
Si vous utilisez Stylelint intensivement pour CSS

---

Verdict 2026 : migrer maintenant ou attendre ?

La réponse dépend de votre contexte. Voici une grille de décision pragmatique.

Migrez maintenant si :

Votre stack est Next.js, Remix, Astro, ou Vite avec TypeScript
Vous n'avez pas de plugins ESLint exotiques
La performance CI est un enjeu (coûts, vitesse de feedback)
Vous démarrez un nouveau projet — c'est le meilleur moment pour éviter ESLint dès le début
Votre équipe est de taille petite à moyenne (2-10 développeurs) et peut absorber la migration en un sprint

Attendez si :

Vous êtes sur SvelteKit et avez besoin du formatage `.svelte` natif
Vous dépendez de plugins ESLint sans équivalent Biome
Vous avez des règles custom JS/TS écrites en interne
Votre organisation impose une configuration ESLint standardisée sur des dizaines de projets

L'approche hybride

Pour beaucoup de projets en 2026, la stratégie gagnante est hybride :

Utiliser Biome comme formateur (remplacement de Prettier) — immédiatement, sans risque
Utiliser Biome pour les règles core (JS/TS quality, React, accessibility de base)
Conserver ESLint uniquement pour les plugins sans équivalent (`import/no-cycle`, règles custom)

Cette approche réduit déjà de 60 à 70% le temps de lint grâce à Biome sur la majorité des fichiers, tout en conservant la couverture ESLint pour les règles critiques.

Pour aller plus loin sur l'outillage de développement, notre analyse de [Bun 2.0 comme alternative à Node.js](/posts/bun-20--lalternative--nodejs-qui-simpose-en-2026) montre que la tendance Rust/performance dans l'outillage JS est durable et s'accélère.

Si vous travaillez sur la performance globale de vos applications, nos articles sur la [performance web et son impact sur les ventes](/posts/vitesse-chargement-site-web-impact-ventes) et sur [WebGPU et la 3D web](/posts/webgpu-et-3d-web--la-nouvelle-frontire-performance-en-2026) donnent une vision complémentaire des enjeux techniques en 2026.

Pour les équipes qui réfléchissent aussi à leur chaîne d'automatisation, notre comparatif [Zapier, Make, n8n](/posts/zapier-make-n8n-comparatif-automatisation) peut vous aider à rationaliser d'autres processus répétitifs au-delà du code.

Et si vous envisagez une refonte technique complète de votre stack, consultez notre guide sur [le coût réel d'une refonte de site web en 2026](/posts/refonte-site-web--combien-a-cote-vraiment-en-2026) pour cadrer le projet avec votre direction.

---

Questions fréquentes sur Biome ESLint Prettier 2026

Biome est-il compatible avec VS Code ?

Oui. L'extension officielle Biome pour VS Code (`biomejs.biome`) est disponible sur le Marketplace. Elle affiche les diagnostics en temps réel, propose les corrections automatiques et formate à la sauvegarde via l'option `editor.defaultFormatter`. Désactivez l'extension Prettier pour éviter les conflits.

Puis-je utiliser Biome avec un monorepo Turborepo ?

Oui, et c'est un excellent cas d'usage. Biome peut être configuré avec un `biome.json` à la racine et des `biome.json` dans chaque package pour des overrides spécifiques. Turborepo peut cacher les résultats Biome comme n'importe quelle tâche. La performance combinée Turborepo + Biome est particulièrement impressionnante.

Biome remplace-t-il aussi Stylelint ?

Partiellement. Biome lint les fichiers CSS avec un jeu de règles de base depuis la version 1.6, mais la couverture est inférieure à Stylelint. Si vous avez des règles CSS complexes (ordre des propriétés, nommage, etc.), conservez Stylelint pour les fichiers CSS/SCSS.

Le formatage de Biome est-il identique à Prettier ?

Non. Biome vise la compatibilité avec Prettier sur les cas courants mais il existe des différences intentionnelles et quelques différences involontaires encore en cours de résolution. Attendez-vous à un diff de formatage au moment de la migration. L'équipe Biome maintient un tracker de compatibilité Prettier dans sa documentation officielle.

Biome supporte-t-il les fichiers `.vue` ?

Non, pas nativement en juin 2026. Le support Vue est une demande très suivie sur GitHub mais n'a pas encore été implémenté. Les projets Vue/Nuxt doivent conserver leur toolchain ESLint actuelle.

---

Biome en 2026 : la bonne décision au bon moment

La question n'est plus "Biome est-il mature ?" — il l'est pour la majorité des stacks frontend modernes. La question est "quel est le bon moment pour mon projet ?". Si vous démarrez un projet Next.js ou Astro aujourd'hui, ne pas commencer avec Biome serait une décision à rebours de la tendance de fond du tooling JavaScript.

Pour les projets existants, la migration est le plus souvent réalisable en une journée de travail pour un développeur senior. Le retour sur investissement — en temps de CI économisé, en configuration simplifiée, en friction de développement réduite — se mesure dès le premier sprint.

Chez ConsilioWEB, nous accompagnons les équipes techniques de PME dans ces migrations de stack, qu'il s'agisse de moderniser la chaîne de qualité de code comme décrit ici, ou de refondre une architecture applicative complète. Si vous souhaitez qu'on audite votre configuration ESLint actuelle et qu'on estime l'effort de migration vers Biome pour votre projet, [contactez notre équipe via le formulaire de devis](/contact) — nous intervenons aussi bien sur des projets Corrèze que sur des missions à distance pour des équipes partout en France.

---

Pour aller plus loin

[Documentation officielle Biome](https://biomejs.dev/guides/getting-started/) — guide de démarrage et référence des règles
[Tracker de compatibilité Biome / Prettier](https://biomejs.dev/formatter/differences-with-prettier/) — liste officielle des différences de formatage
[Dépôt GitHub Biome](https://github.com/biomejs/biome) — issues, roadmap plugins GritQL et discussions de la communauté
[Benchmark Biome vs ESLint](https://github.com/biomejs/biome/tree/main/benchmark) — scripts de benchmark reproductibles inclus dans le dépôt officiel
[Action GitHub officielle `biomejs/setup-biome`](https://github.com/biomejs/setup-biome) — documentation de l'action CI avec toutes les options disponibles

Biome : remplacer ESLint + Prettier par un seul outil 10x plus rapide