📏 Comment on code ici
Ce dépôt est fait pour que la plus grande partie du code soit écrite avec l'aide d'un assistant IA. Un assistant produit du code qui a l'air juste. Ce qui fait la différence entre « a l'air juste » et « est juste », ce n'est pas la relecture : c'est l'outil qui refuse de laisser passer.
La règle des règles : une règle que personne ne vérifie n'est pas une règle, c'est un souhait. Si tu ajoutes une convention quelque part sans l'outiller, elle aura disparu dans trois semaines — pas par mauvaise volonté, simplement parce que personne ne peut tout retenir.
Alors oui, c'est strict. Mais c'est strict à notre place : personne n'a besoin de retenir ces dix règles, ni de les faire respecter en revue. La machine s'en charge, et on garde notre énergie pour les vraies questions. 😌
🛡️ Les dix règles
Chacune est vraiment vérifiée par un outil. Aucune n'est une simple recommandation.
🚪 On ne prend pas la sortie de secours
En TypeScript, il existe plusieurs manières de dire au compilateur « tais-toi » : écrire `any`, ajouter un commentaire qui ignore l'erreur, forcer une valeur avec un point d'exclamation. Un assistant IA bloqué prend systématiquement la première qu'il trouve, et l'erreur ressort en production. Ces portes sont donc fermées.
VérifiéeLe linter refuse ces trois écritureseslint.config.mjs🔒 Les types vont jusqu'au bout
Quand on écrit `resultats[0].nom`, TypeScript considère par défaut que le premier résultat existe. Si la liste est vide, ça plante — mais chez la personne qui visite le site, pas chez nous. On demande au compilateur d'être méfiant à notre place.
VérifiéeOptions strictes du compilateurtsconfig.base.json🎨 Aucune couleur écrite à la main
Une couleur écrite en dur ne suivra pas la prochaine mise à jour du thème. Et personne ne le remarquera avant que l'écran soit en production, avec un rouge qui ne ressemble à aucun autre rouge du produit.
VérifiéeVérification du CSS et du TypeScriptstylelint.config.mjs · eslint.config.mjs🧱 Un seul fichier de styles pour tout le produit
On a compté ce que donne l'absence de cette règle : 159 classes inventées à la main sur les anciens projets, dont 99 qui n'existaient que dans un seul projet et 20 qui écrasaient silencieusement des composants DaisyUI. Chacun avait refait la même carte, le même badge, un peu différemment.
Vérifiéepnpm check:components refuse tout CSS ailleursscripts/check-components.mjs📖 Tout composant est visible dans le design
Un composant qu'on ne peut pas voir sera réinventé par la personne suivante, forcément un peu différent. Déclarer un composant le fait apparaître automatiquement dans la section design.
Vérifiéepnpm check:components compare le registre et le CSSpackages/ui/src/registry.ts🖥️ Pas de code navigateur pendant la génération des pages
Nos pages sont fabriquées sur un serveur, où il n'y a ni fenêtre ni document. Un code qui les utilise au mauvais moment ne plante qu'une fois en ligne.
VérifiéeLe linter bloque ces usages dans les composantseslint.config.mjs⏳ Aucune dépendance de moins de sept jours
Quand un paquet npm est compromis, il est presque toujours repéré et retiré dans les heures qui suivent sa publication. Attendre une semaine suffit à laisser passer l'orage sans nous. Le prix à payer : on n'a jamais la toute dernière version.
Vérifiéepnpm refuse d'installer un paquet trop récentpnpm-workspace.yaml🛑 Aucun script d'installation sans autorisation
Certains paquets exécutent du code au moment de leur installation. C'est le moyen le plus courant de faire tourner quelque chose de malveillant sur nos machines. Chaque autorisation est donc une décision consciente, écrite noir sur blanc.
VérifiéeListe blanche explicitepnpm-workspace.yaml🔑 Aucun secret dans l'historique
Un mot de passe ou une clé publiée par erreur reste dans l'historique du dépôt même après avoir été supprimée. Deux outils différents vérifient chaque commit, parce qu'ils ne détectent pas les mêmes choses.
VérifiéeDeux scanners avant chaque commitlefthook.yml📝 Des messages de commit qui servent à quelque chose
« feat: ajoute la recherche » ne dit pas où. Le dépôt démarre de zéro : autant que l'historique soit lisible dès le premier jour.
VérifiéeFormat et périmètre obligatoirescommitlint.config.ts
🚧 Et quand ça bloque ?
La première réaction n'est pas de désactiver la vérification, mais de se demander ce que le code essaie de nous dire. Neuf fois sur dix, la règle a raison.
S'il s'avère qu'elle est vraiment trop stricte, c'est une discussion à avoir, et un commit à part — jamais une exception glissée discrètement au milieu d'autre chose. Une désactivation ponctuelle doit être accompagnée d'une explication d'au moins vingt caractères, qui ditpourquoi et pas quoi.
⌨️ Les commandes du quotidien
Une seule est vraiment obligatoire : pnpm verify doit passer avant d'annoncer qu'une tâche est terminée. Pas « ça devrait marcher » — soit la commande passe, soit le travail n'est pas fini.
| Commande | Ce qu'elle fait |
|---|---|
✅ pnpm verify | Lance toutes les vérifications d'un coup. C'est la commande à passer avant de dire qu'on a fini. |
🚀 pnpm docs | Ouvre cette documentation en local. |
🔧 pnpm lint:fix | Corrige automatiquement ce qui peut l'être. |
💅 pnpm format:fix | Remet le code en forme. |
🧩 pnpm check:components | Vérifie qu'aucun composant ne s'est glissé hors du design system. |
🎯 pnpm fonts:sync | Récupère les dernières icônes de catégories depuis l'ancien dépôt. |