← Blog · 30 avril 2026 · L'équipe ConvertCaseHQ · 7 min de lecture

camelCase ou PascalCase : quelle différence ?

La seule différence entre camelCase et PascalCase, c'est la première lettre. camelCase commence par une minuscule et met une majuscule à chaque mot suivant (userName, parseResponse). PascalCase met une majuscule à chaque mot, y compris le premier (UserName, ResponseParser). Par convention, PascalCase désigne les types (classes, interfaces, enums, composants React) et camelCase les valeurs et les actions (variables, fonctions, méthodes, propriétés).

Cette unique majuscule porte plus d'information qu'il n'y paraît. Voici ce qu'elle signale, les langages où elle est imposée et pas seulement recommandée, et le point sur lequel personne ne s'accorde : les sigles.

camelCase ou PascalCase en un coup d'œil

Attention au vocabulaire quand vous lisez des guides de style. Beaucoup de gens disent « camel case » pour les deux styles, et PEP 8 cite même CamelCase comme autre nom de CapWords, son terme pour PascalCase. Si le sens d'un guide n'est pas évident, regardez ses exemples.

Pourquoi la première lettre compte : types et valeurs

La convention vous permet de lire du code sans rien aller vérifier. Dans const invoice = new Invoice(order), vous voyez d'un coup d'œil que Invoice est ce que vous construisez et invoice ce que vous obtenez en retour. Les signatures TypeScript fonctionnent de la même façon : dans function total(order: Order): Money, le nom en minuscules est la valeur et les noms qui commencent par une majuscule sont des types.

Elle permet aussi à un même mot de nommer à la fois un type et une valeur sans conflit, ce qui arrive sans arrêt : user: User, config: Config, request: Request. Dans un langage sensible à la casse, ce sont des identifiants différents, et la majuscule indique au lecteur lequel est lequel.

Là où le langage l'impose

En JavaScript, Java, C# et Python, la casse d'un nom de classe n'est qu'une convention. Rien ne vous empêche d'écrire class invoice. En JavaScript, vous pouvez transformer la convention en vérification avec la règle new-cap d'ESLint : par défaut, elle signale new invoice(), et elle signale aussi l'appel sans new d'une fonction à majuscule comme Invoice(), ce qui trahit en général un bug. Quelques langages et frameworks vont plus loin et intègrent la règle.

Go : la première lettre fixe la visibilité

Go n'a pas de mots-clés public ou private. Un nom de niveau paquet, un champ de struct ou une méthode est exporté si sa première lettre est une majuscule, et privé à son paquet si c'est une minuscule. Choisir entre PascalCase et camelCase, c'est choisir la visibilité.

package shapes

import "math"

// Circle is exported, so other packages can use it.
type Circle struct {
	Radius float64 // exported field
	label  string  // unexported field
}

// Area is exported.
func Area(c Circle) float64 { return math.Pi * square(c.Radius) }

// square is unexported: only code inside package shapes can call it.
func square(x float64) float64 { return x * x }

c := shapes.Circle{Radius: 2}
fmt.Println(shapes.Area(c))   // fine
fmt.Println(shapes.square(2)) // compile error: square is not exported

C'est aussi pourquoi Effective Go indique qu'un accesseur pour un champ non exporté owner doit s'appeler Owner, et non GetOwner. La majuscule vous dit déjà qu'il s'agit de l'accès public.

React : les composants doivent commencer par une majuscule

La documentation de React est sans détour : les noms de composants doivent commencer par une majuscule, sinon ils ne fonctionnent pas. JSX traite une balise en minuscules comme <section> comme un élément HTML, et une balise avec majuscule comme <OrderSummary /> comme votre composant.

Ruby : les noms de classe sont des constantes

En Ruby, tout nom qui commence par une majuscule est une constante, et les noms de classe doivent être des constantes. class Invoice fonctionne ; class invoice provoque une erreur de syntaxe (« class/module name must be CONSTANT »).

Lequel utiliser, langage par langage

• JavaScript et TypeScript : camelCase pour les variables, fonctions, méthodes et propriétés ; PascalCase pour les classes, interfaces, alias de type, enums et composants.
• Java et Kotlin : la même répartition, plus des majuscules séparées par des underscores pour les vraies constantes (MAX_RETRIES).
• C# : PascalCase y est bien plus répandu que dans les autres langages. Méthodes, propriétés, événements, champs publics, espaces de noms et même constantes sont en PascalCase ; camelCase est réservé aux paramètres et aux variables locales, avec _camelCase pour les champs privés. Une signature typique ressemble à public decimal CalculateTotal(decimal taxRate).
• Swift : PascalCase pour les types et les protocoles, camelCase pour tout le reste.
• Go : celui qui correspond à la visibilité voulue.
• Python : PascalCase pour les classes uniquement. Les fonctions et les variables sont en snake_case, et PEP 8 n'autorise camelCase que là où c'est déjà le style dominant d'un code plus ancien.
• PHP (PSR-1) : classes en PascalCase, méthodes en camelCase.

Pour les constantes, les fichiers et le reste, consultez notre aide-mémoire des styles de casse pour développeurs.

Le point délicat : sigles et acronymes

Faut-il écrire userId ou userID ? HttpClient ou HTTPClient ? Les grands guides de style ne donnent pas la même réponse :

Notre avis : si le guide de votre langage a une règle, suivez-la, car c'est ce qu'attendent la bibliothèque standard et vos collègues. S'il n'en a pas, traitez les sigles comme des mots (HttpClient, userId). Les limites entre les mots restent visibles quand deux sigles se suivent (comparez XMLHTTPRequest et XmlHttpRequest), et les noms survivent à la conversion automatique d'un style de casse à l'autre. Même le XMLHttpRequest du navigateur mélange les deux approches dans un seul nom.

Pour aller plus loin, les conventions de mise en majuscules de Microsoft sont un bon exemple d'ensemble complet de règles rédigé sur une seule page.

Convertir entre camelCase et PascalCase

Pour un nom simple, la conversion tient en un caractère : changez la casse de la première lettre.

const toPascal = (s) => s.charAt(0).toUpperCase() + s.slice(1);
const toCamel = (s) => s.charAt(0).toLowerCase() + s.slice(1);

toPascal("orderTotal"); // "OrderTotal"
toCamel("OrderTotal");  // "orderTotal"
toCamel("HTMLParser");  // "hTMLParser" (acronyms need a smarter split)

Cette dernière ligne explique pourquoi les outils découpent d'abord les noms en mots. Voici ce que produit le convertisseur de casse de ConvertCaseHQ pour quelques entrées délicates :

Il découpe aux majuscules existantes et écrit les sigles comme des mots, ce qui correspond à la règle de Google. Si votre projet suit les règles de Go, de .NET ou de PEP 8 pour les sigles, corrigez ces noms à la main ensuite (getUserId devient getUserID en Go). Les noms de marque sont l'autre piège : aucun algorithme ne sait que IPhone a l'air faux.

Deux erreurs faciles à éviter

La première consiste à mettre une majuscule à une instance : const Cart = new ShoppingCart() fait passer Cart pour une deuxième classe, et le prochain lecteur ira chercher sa définition. La seconde est une fonction utilitaire en PascalCase en JavaScript, comme function FormatPrice(). Sauf s'il s'agit d'un constructeur ou d'un composant React, les lecteurs supposeront qu'elle exige new ou du JSX, et new-cap se plaindra si vous l'appelez sans l'un ni l'autre.

Une règle simple

Si c'est un type, ou quelque chose que vous construisez avec new, utilisez PascalCase. Si c'est une valeur ou une action, utilisez camelCase. Laissez le guide de votre langage trancher pour les sigles, et un linter retenir le reste à votre place. Pour les spécificités de JavaScript, y compris les constantes et les champs privés, consultez notre guide de nommage en JavaScript.