L’art d’être MANIAC

Maniac « Qui s’attache avec un goût et un soin excessifs à des détails. » – Larousse

Précédemment…

Il y a quelques temps, j’ai eu l’occasion de donner une conférence sur un sujet qui me tient particulièrement à cœur : la rigueur outillée. Un thème qui, à première vue, peut sembler bien terre-à-terre… mais qui, en pratique, conditionne la santé mentale de toute une équipe de développement !

Le choix du titre de cette présentation, « MANIAC », n’est pas anodin. On y trouve en filigrane tous les outils dont je vais vous parler : EditorConfig, Prettier, ESLint, Stylelint, Husky, sans oublier, la nouvelle vague OXC. L’idée n’est pas de vous vendre une configuration stricte à outrance, mais plutôt de vous montrer comment, avec quelques fichiers bien pensés, on évite des débats interminables, des git diff illisibles, et des commits instables dès le lendemain matin.

EditorConfig : Le Socle Commun

Tout commence (presque) toujours de la même manière ; une équipe se forme, chacun avec ses préférences de développement/son éditeur de prédilection :

Le Dev A 🧑‍💻 jure par VSCode et ses fins de ligne CRLF
Le Dev B 👩🏼‍💻 ne quittera IntelliJ pour rien au monde (encodage UTF-16 en prime)
Et le Dev C 👨🏾‍💻, code encore sous Vim en LF (parce que pourquoi pas…)

Résultat ? Un simple git diff sur un unique fichier modifié se transforme en une pléthore de +512 / -512 lignes, noyant la moindre review de Pull Request sous des changements d’encodage totalement invisibles à l’œil nu…

La solution, ici, tient en un seul fichier, minuscule mais salvateur : .editorconfig

root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true

[*.{js,jsx,ts,tsx}]
indent_size = 2
indent_style = space

[src/**.java]

indent_size = 4 indent_style = tab [*.md] trim_trailing_whitespace = false

NB : La véritable force d’EditorConfig, c’est d’être agnostique de l’éditeur. Que vous soyez sur VSCode, IntelliJ ou Vim, le fichier sera lu et appliqué automatiquement (à condition d’avoir l’extension adéquate, mais la plupart des IDE modernes le supportent nativement, sans installation supplémentaire). C’est littéralement le socle commun sur lequel tout le reste va pouvoir se construire.

Prettier : Un Style Pour Les Gouverner Tous

Une fois l’encodage et l’indentation mis d’accord, un autre type de débat émerge inévitablement ; cette fois-ci sur le style du code lui-même :

« On devrait utiliser des double-quotes, c’est mieux« , lance le Dev A 🧑‍💻 en réunion ;
« Pourquoi ?« , répond le Dev B 👩🏼‍💻
Le Dev A 🧑‍💻, à nouveau : « Pour uniformiser ! Le template utilise déjà des double-quotes…«
Et le Dev C 👨🏾‍💻, qui n’a pas dit son dernier mot, rétorque qu’on pourrait justement différencier les vues de la logique via des single quotes.

Le constat ? Encore un git diff de +512 / -512 lignes, mais cette fois purement stylistique, et des désaccords qui ne trouveront jamais de fin naturelle en réunion d’équipe.

C’est précisément le rôle du Formater que de trancher ce genre de débat, une bonne fois pour toutes. Avec Prettier (ou son équivalent), il suffit d’un fichier de configuration pour que le sujet soit clos :

// .prettierrc
{
  "arrowParens": "always",
  "bracketSameLine": true,
  "printWidth": 120,
  "singleQuote": false,
  "trailingComma": "es5"
}

Une fois cette configuration en place, prettier --write "src/**/*.{js,jsx,ts,tsx}" suffit à remettre tout le monde d’accord, sans discussion. Et au-delà de l’aspect purement technique, il y a un vrai bénéfice psychologique à l’usage d’un Formater : toute l’équipe adhère (puisque personne ne décide seul dans son coin), zéro friction dans les Pull Requests, et globalement… l’équipe respire mieux.

ESLint : Identifier Et Corriger Les Problèmes

Il faut ici mentionner une nuance essentielle (que je rappelle lorsque l’occasion se présente) : Un Linter n’est pas un Formater ! Le premier détecte les problèmes algorithmiques (variable non utilisée, promesse jamais résolue, faille potentielle…), le second se contente de mettre en forme le code pour la lisibilité. Les confondre, c’est se priver de la moitié des bénéfices de l’outillage.

Prenons un cas concret :

Le Dev A 🧑‍💻 écrit une async function() sans jamais utiliser ni await, ni .then()
Puis, il enchaîne directement avec un git add . && git commit
Le Dev C 👨🏾‍💻, un peu plus tard, s’étonne : « Ta promesse n’est jamais résolue !?«

Malheureusement, le mal est fait ! Cela peut provoquer du code instable, des bugs silencieux, et de la dette technique qui s’accumule sans bruit. C’est exactement ce que le Linter, ESLint, est censé attraper en amont.

// eslint.config.js
export default [
  js.configs.recommended,
  ...tslint.configs.recommended,
  prettier,
  {
    plugins: { "react-hooks": reactHooks },
    rules: {
      "no-console": "error",
      "no-unused-vars": "warn",
      "react-hooks/rules-of-hooks": "error",
      "react-hooks/exhaustive-deps": "warn"
    }
  }
];

NB : Le passage de la version 8 à la version 9 d’ESLint n’est pas anodin. Avec la v8, on empile des presets, ce qui rend les règles implicites et donc difficilement maintenables sur la durée. Avec la v9, les configurations sont explicites, les règles visibles d’un simple coup d’œil, et les performances meilleures.

Et le CSS, dans tout ça ? 🤔 On a trop souvent tendance à l’oublier, tant l’attention se porte sur le JavaScript et le TypeScript. Pourtant, les mêmes débats stériles s’y invitent :

Le Dev A 🧑‍💻 n’a aucune préférence sur l’ordre des règles CSS « du moment que ça marche«
Le Dev B 👩🏼‍💻 préfère organiser position, puis margin et padding, puis width et height, etc…
Enfin, le Dev C 👨🏾‍💻 isole systématiquement les propriétés des media queries, jugées plus « Mobile-First »

Résultat ? De la duplication de .selectors, et une lisibilité (notamment lors des review) qui en pâtit sérieusement… Stylelint répond au même besoin, mais côté feuilles de style :

// .stylelintrc
{
  "extends": ["stylelint-config-standard"],
  "plugins": ["stylelint-order"],
  "rules": {
    "order/properties-order": ["position", "display", "padding", "margin"]
  }
}

Husky : Contrôlez Vos Commits

Configurer tous ces outils, c’est bien. Encore faut-il s’assurer qu’ils soient réellement exécutés ! Or, dans la vraie vie, l’équipe connaît très souvent l’existence de la commande npm run lint… mais ne l’utilise jamais :

Le Dev B 👩🏼‍💻 pousse tranquillement un commit avec le message « fix: trust me I’m an engineer«
Plus tard, le Dev C 👨🏾‍💻 se plaint que « ça ne fonctionne pas sur mon poste !«

Encore une fois, du code instable, un ✖ 3 problems (1 error, 2 warnings) qui traîne dans un coin, et une CI/CD qui finit immanquablement par planter.

C’est là qu’intervient Husky 🐶, l’orchestrateur qui vient garantir que rien n’échappe à la vigilance du Linter et du Formater, dès le commit :

# .husky/pre-commit
npx lint-staged

// package.json
{
  "lint-staged": {
    "*.{css,scss}": ["stylelint", "prettier --write"],
    "*.{js,jsx,ts,tsx}": ["eslint", "prettier --write"]
  }
}

NB : Husky n’est ni plus ni moins qu’un wrapper JavaScript autour des GitHooks natifs (.git/hooks). Grâce à lui, plus aucun commit « douteux » ne peut atteindre le dépôt distant sans être passé, au préalable, par la case linting / formatage. Une discipline imposée, certes, mais totalement implicite pour l’équipe.

OXC : L’outillage Moderne

The JavaScript Oxidation Compiler

L’écosystème JavaScript/TypeScript connaît depuis peu une petite révolution, portée par l’équipe VoidZero (fondée par Evan You) : OXC – « The JavaScript Oxidation Compiler« . Deux outils en particulier valent le détour :

Oxlint, un Linter écrit en 🦀 Rust, jusqu’à 50 fois plus rapide qu’ESLint, avec une détection des erreurs de type et une compatibilité grandissante avec l’écosystème existant.

// oxlint.json
{
  "extends": ["recommended", "typescript"],
  "plugins": ["react"],
  "rules": {
    "no-console": "error",
    "no-unused-vars": "warn",
    "react/rules-of-hooks": "error",
    "react/exhaustive-deps": "warn"
  }
}

Et Oxfmt, son pendant côté formatage, environ 30 fois plus rapide que Prettier, avec un tri natif des import (fini les conflits de merge inutiles sur ce genre de détail) et un support du /* JSDoc */ ainsi que de Tailwind :

// .oxfmtrc.json
{
  "arrowParens": "always",
  "bracketSameLine": true,
  "jsdoc": {
    "commentLineStrategy": "multiline"
  },
  "printWidth": 120,
  "singleQuote": false,
  "trailingComma": "es5"
}

NB : Oxlint conserve la compatibilité avec une grande partie des règles ESLint, tandis qu’Oxfmt mise sur un formatage simple et déterministe (à la manière de Biome). Le tri natif des import évite les conflits de merge, tout en offrant une lisibilité immédiate du fichier. De quoi se poser légitimement la question : ESLint ou Oxlint ? Tout est question de curseur entre maturité et vitesse.

Cela dit, cette nouvelle génération d’outils ne doit pas devenir un nouveau prétexte pour tomber dans l’excès inverse : ~~Activer 512+ règles ! Corriger le moindre warning !~~ Non ! Activez plutôt ce qui est vraiment utile à votre équipe. Car une configuration simple garantit un code propre et maintenable. Être pragmatique, ce n’est pas être laxiste ; c’est simplement s’adapter à l’action concrète, plutôt que de détruire d’avance toute objection au nom d’un dogme de configuration.

Conclusion

Être « MANIAC », ce n’est donc pas une question de perfectionnisme stérile, mais bien une manière de garantir la cohérence, la lisibilité et la maintenabilité d’un projet à l’échelle. EditorConfig pose le socle commun, agnostique de l’éditeur, sans la moindre installation nécessaire. Le Formater (Prettier ou Oxfmt) garantit un style de code unique pour une équipe saine (n’oubliez pas d’activer le formatOnSave de votre IDE). Le Linter (ESLint, Stylelint ou Oxlint) veille sur la qualité et la sécurité de votre code (gotta catch ’em all 🐞) avant le déploiement. Enfin, Husky automatise tout cela en s’appuyant sur les GitHooks, pour instaurer une discipline implicite, sans effort conscient de la part de l’équipe.

Et contrairement à ce qu’on pourrait penser, tout ceci n’est pas contradictoire avec le pragmatisme : bien au contraire, une configuration simple et bien pensée vous fera gagner un temps précieux (et quelques cheveux blancs en moins). Quant au Backend, si vous êtes sur une Stack JavaScript/TypeScript, les mêmes outils s’appliquent directement ; sinon, EditorConfig et les GitHooks (via scripting) restent vos meilleurs alliés. Et pour SonarQube ? Tout est affaire de contexte d’entreprise, entre qualité de code à court terme, et vision à long terme. Mais ceci est une autre histoire…

Damien CHAZOULE – Talk « l’art d’être maniaque » – DevQuest 2026