TypeScript en équipe : style de code, conventions et zéro chaos

Pourquoi « ça marche » n’est pas suffisant en équipe ?

Imaginez : vous ouvrez une PR d’un collègue, et là, du any à chaque étape, des variables nommées a, b, c, et tout est formaté comme si le code avait été écrit par un chat marchant sur le clavier. Ça vous dit quelque chose ? Seul, on peut encore survivre à ce genre de code. Mais en équipe, c’est le chemin vers les conflits, les bugs et les nuits blanches en revue de code.

Aujourd’hui, nous allons voir comment faire de TypeScript en équipe non pas un simple outil, mais une base solide. Nous aborderons le style de code et les conventions qui vous épargneront des nerfs et accéléreront le développement. Sans pédanterie, avec des exemples concrets.

1. Typage strict : votre premier allié

TypeScript, c’est une histoire de types. Mais beaucoup d’équipes l’utilisent comme un « TypeScript-lite », en laissant du any partout où ils ont la flemme de réfléchir. Cela tue toute la magie. Première convention : interdire any.

Mauvais :

function fetchData(url: string): any {    // ...}

Bon :

interface ApiResponse {    id: number;    name: string;    isActive: boolean;}

function fetchData(url: string): Promise<ApiResponse> {    // ...}

Lorsque chaque développeur décrit explicitement ce qu’il retourne et ce qu’il accepte, le code devient auto-documenté. Vous n’avez plus à deviner : « Ce data, c’est une chaîne ou un objet ? ». Les types parlent d’eux-mêmes.

2. ESLint + Prettier : une configuration qui ne se discute pas

Si votre équipe n’a pas encore de linter et de formateur unifiés, arrêtez-vous et configurez-les maintenant. ESLint détecte les erreurs logiques et les violations du style de code, tandis que Prettier uniformise le code.

Configuration de base ESLint pour TypeScript :

{  "parser": "@typescript-eslint/parser",  "plugins": ["@typescript-eslint"],  "extends": [    "eslint:recommended",    "plugin:@typescript-eslint/recommended",    "prettier" // obligatoirement à la fin  ],  "rules": {    "@typescript-eslint/no-explicit-any": "error",    "@typescript-eslint/explicit-function-return-type": "warn",    "no-console": "warn"  }}

Ajoutez Prettier avec des règles simples : des tabulations au lieu d’espaces (ou l’inverse, mais uniforme), des guillemets simples, un point-virgule à la fin. Et activez formatOnSave dans votre IDE. Cela vous évitera des débats sans fin sur les indentations.

3. Nommage : parlez le même langage

Les conventions de nommage, c’est comme le code de la route. Sans elles, c’est le chaos. En TypeScript, les conventions suivantes sont courantes :

• camelCase pour les variables, fonctions, méthodes : getUserData(), userName
• PascalCase pour les classes, interfaces, types : UserProfile, ApiResponse
• UPPER_SNAKE_CASE pour les constantes connues au moment de la compilation : MAX_RETRY_COUNT, DEFAULT_TIMEOUT
• Préfixe I pour les interfaces — sujet à débat, mais de nombreuses équipes l’utilisent : IUser. Décidez-en dès le départ.

Exemple de mauvais nommage :

const data = { n: 'Alex', a: 30 }; // que sont n et a ?

Bon :

const userProfile = { name: 'Alex', age: 30 };

4. Structure du projet : ne cachez pas tout dans un seul fichier

Quand le projet grandit, l’absence de structure est l’ennemi numéro un. Mettez-vous d’accord sur les dossiers à l’avance. Voici une option populaire pour un projet TypeScript :

• src/ — code source
• src/components/ — composants UI (si React)
• src/utils/ — fonctions utilitaires
• src/types/ — types et interfaces globaux
• src/services/ — interaction avec l’API
• src/hooks/ — hooks personnalisés (si React)
\