Retour au parcours
Conventions DSI
Branches, commits et structure du code.
Quelques règles simples pour que le code reste lisible et que les livraisons se passent sans accroc, quelle que soit la personne (ou l'Agent) qui contribue.
Les noms de branches
Une branche par sujet, nommée clairement. Le format : type/description-courte, en anglais.
type
Un préfixe de type
La branche commence par sa nature : feat/, fix/, chore/… puis une courte description en anglais.
kebab
Des tirets, pas d’espaces
On écrit en minuscules avec des tirets. Ex. feat/add-logout-button (jamais d’espaces ni d’accents).
( )
Pas de parenthèses
Les parenthèses et caractères spéciaux cassent certains outils Git : on les évite dans les noms de branches.
Les messages de commit
Format : type(scope): description, en anglais, sur une seule ligne. Le type décrit la nature du changement :
feat
Nouvelle fonctionnalité
Ajoute un comportement visible. Ex. feat(auth): add logout button.
fix
Correction de bug
Répare quelque chose de cassé. Ex. fix(header): correct user initials.
refactor
Réorganisation
Change le code sans changer le comportement.
docs
Documentation
Mise à jour de la doc ou des commentaires.
test
Tests
Ajout ou correction de tests, sans code applicatif.
chore
Maintenance
Dépendances, configuration, outillage.
La structure du code
Le projet suit une architecture par domaines (DDD) côté serveur, en ESM uniquement. Les briques techniques sont fixées : MUI 9 pour l'interface, Prisma pour la base de données, Vitest pour les tests, Pino pour les logs. On garde la cohérence plutôt que d'ajouter de nouvelles librairies.
Aperçu des règles ESLint
ESLint veille à la qualité en continu (zéro avertissement toléré). Les principales règles :
no-any
Pas de any
Le type any est une erreur, pas un avertissement. On type correctement les données.
no-log
Pas de console.log
Côté serveur, on logue avec Pino. Les console.log oubliés sont signalés.
size
Limites de taille
Fonctions courtes (≈ 25 lignes), fichiers raisonnables (≈ 250 lignes), profondeur d’imbrication limitée.
cmplx
Complexité maîtrisée
Une fonction trop ramifiée est refusée : on la découpe en sous-fonctions plus simples.
Tout en anglais, sauf l'écran
Code, commits et commentaires sont en anglais. Seule exception : les textes affichés à l'utilisateur, qui restent en français.
Le push passe par GitLab
On ne pousse pas en direct depuis Replit : le code part via l'API GitLab, et chaque message de commit doit passer la validation commitlint avant d'être accepté.
La charte complète
Ces conventions découlent de la charte de développement « Vibecoding responsable » définie par l'architecte DSI.