Convertisseur de casse : camelCase, snake_case et Title Case expliqués

La casse du texte est un système de nommage, et il y a plus de styles qu'on ne peut en nommer. Ceux que vous rencontrez quotidiennement sont UPPERCASE et lowercase, les deux extrêmes ; Title Case, qui met une majuscule à chaque mot ; sentence case, qui ne met une majuscule qu'au premier ; et les deux styles de programmation, camelCase et snake_case, plus leurs cousins PascalCase, kebab-case et CONSTANT_CASE.

Chaque style a un foyer, et les foyers ne sont pas interchangeables. camelCase appartient aux variables JavaScript ; snake_case à Python et à la plupart des colonnes de base de données ; Title Case aux titres ; sentence case au texte courant. Convertir entre eux est mécaniquement facile et sémantiquement lossy, ce qui est toute la tension.

Trois faits expliquent presque tous les problèmes liés à la casse. La casse détruit l'information — le texte en majuscules ne peut pas être restauré à sa forme d'origine, parce que les capitales des noms propres sont parties. La casse est sensible à la locale — la même lettre se convertit différemment en turc qu'en anglais. Et les styles de casse s'affrontent aux frontières — quand un frontend camelCase rencontre une API snake_case, un côté doit traduire, et cette traduction est un site de bug classique.

Le reste de cet article couvre où appartient chaque style, les guerres de nommage dans le code et les API, comment récupérer du texte arrivé en MAJUSCULES, les pièges des accents et des locales, la conversion en masse pour les tableurs, et la question de lisibilité des titres versus la casse phrase. Si vous avez juste besoin d'une conversion, le convertisseur de casse gère tous les styles courants au même endroit.

Les styles de casse et où chacun appartient

Appliqués à la même phrase, voici ce que chaque style produit et où vous le trouverez attendu :

La compétence utile n'est pas de mémoriser la liste mais de reconnaître un style au premier coup d'œil et de savoir lequel le contexte attend. Quand une valeur semble « wrong » dans une base de code, une inadéquation avec ce tableau en est généralement la cause.

Les guerres de nommage : camelCase contre snake_case

Les communautés ont choisi leurs conventions il y a des décennies et ne se sont jamais mises d'accord. JavaScript, Java et C# sont allés au camelCase pour les variables parce qu'il se lit vite et économise un caractère. Python, Ruby et le monde SQL sont allés au snake_case parce qu'il est non ambigu et plus facile à lire dans les noms longs. Ni l'un ni l'autre n'a tort ; les deux sont ancrés.

La friction apparaît à la frontière entre deux systèmes. Un frontend JavaScript envoie userName ; un backend Python attend user_name. Quelque part entre les deux, une conversion doit se faire, et les bugs classiques vivent là : un champ converti deux fois et finissant user_name des deux côtés d'une autre frontière, ou une clé non convertie si bien que le backend reçoit silencieusement un champ qu'il ne reconnaît pas.

• Choisissez une convention par couche et convertissez à la frontière, pas partout dans le code.
• Soyez explicite sur la frontière. Une seule transformation documentée entre l'API et le stockage vaut mieux qu'une conversion de casse éparpillée dans la base de code.
• Méfiez-vous des renommages automatisés. Les outils de refactorisation qui « corrigent » la casse dans tout un projet peuvent casser des contrats d'API, parce que les consommateurs externes envoient toujours les anciens noms de champs.

La documentation de l'API est la vérité de terrain. Quoi que dise votre guide de style de code, le format filaire est ce que l'autre système parle réellement.

Récupérer le texte arrivé en MAJUSCULES

Un tableur ou un e-mail en capitules est une nuisance courante, et la solution est un processus en deux étapes plutôt qu'un seul bouton. La raison est que les majuscules sont destructives : elles jetent le modèle de capitalisation de l'original, et aucun outil ne peut le reconstruire à partir de rien.

La séquence fiable consiste à d'abord tout convertir en minuscules, ce qui est exact et ne perd rien de plus, puis à appliquer le Title Case ou la sentence case pour obtenir la forme souhaitée. Ce que vous tenez alors est mostly correct — « HELLO WORLD » devient « Hello World » — avec les noms propres encore faux, parce qu'un outil ne peut pas savoir que « paris » devrait être « Paris » ou que « mcdonald » devrait être « McDonald ».

Cette dernière passe est humaine, et il n'y a pas moyen d'y échapper pour le texte où les noms comptent. Pour une liste de descriptions de produits ou une note interne rapide, le résultat automatisé est généralement suffisant ; pour tout ce qui est destiné au client, prévoyez deux minutes pour le relire.

Le corollaire à retenir : ne mettez jamais en majuscules un texte original dont vous pourriez avoir besoin plus tard. Conservez le fichier original et travaillez sur une copie, parce qu'une fois les capitales parties, elles sont parties.

Accents, locales et le piège du i turc

Pour du texte ASCII pur, la conversion de casse est ennuyeuse et fiable. Dès que des accents ou d'autres écritures entrent en jeu, cela devient intéressant, parce que « majuscules » n'est pas une idée universelle unique.

• Les lettres latines accentuées font généralement l'aller-retour correctement. Un convertisseur moderne gère é, ü et ñ correctement dans les deux sens.
• Le i pointé turc. En turc, un I majuscule passe en minuscule en un ı sans point, tandis qu'un i avec point passe en majuscule en un İ capital. Appliquez les règles anglaises à du texte turc et vous le corrompez silencieusement. Il en va de même pour l'azéri et quelques autres locales.
• Le eszett allemand. Le ß minuscule n'a pas de lettre majuscule unique — il devient SS, deux caractères. L'aller-retour négligemment change la longueur de la chaîne, ce qui casse des choses comme les champs de base de données à largeur fixe.
• Les écritures sans casse du tout. L'arabe, l'hébreu, le thaï et la plupart des autres écritures n'ont pas de majuscules ni de minuscules, donc « convertir en majuscules » est une opération nulle que certains outils implémentent comme un passage silencieux et d'autres comme une erreur.

Si votre texte est turc, allemand, grec ou dans une écriture non latine, confirmez que l'outil est sensible à la locale avant de faire confiance au résultat. Un convertisseur qui suppose l'anglais va bien pour l'anglais et se trompe pour tout le reste.

Conversion en masse pour les tableurs et les CSV

Une cellule à la fois n'est pas un flux de travail. Le modèle fiable pour une colonne entière est de la coller dans un convertisseur qui respecte la structure des lignes, de choisir la casse cible, et de coller le résultat en retour — l'exigence clé étant que l'outil traite chaque ligne comme sa propre valeur au lieu de tout joindre en un seul paragraphe.

• Dans un tableur, les fonctions UPPER(), LOWER() et PROPER() font le travail sur des données en direct, et ont la même faiblesse sur les noms propres que n'importe quel Title Case.
• Vérifiez le nombre de lignes avant et après. Un outil qui supprime les lignes vides ou fusionne les lignes enveloppées va discrètement désynchroniser votre colonne, et l'erreur n'apparaîtra que quand quelqu'un lira la mauvaise valeur.
• Conservez la colonne d'origine jusqu'à ce que vous ayez vérifié le résultat. Les opérations en masse sont précisément à l'échelle où une petite erreur devient une grosse.

Pour un CSV destiné à un import, confirmez d'abord la convention de casse attendue par le système récepteur. Beaucoup de systèmes d'e-commerce et d'ERP traitent les en-têtes de colonnes de manière sensible à la casse, donc une ligne d'en-tête convertie en Title Case peut faire échouer l'import d'un fichier par ailleurs valide.

Titres contre casse phrase pour la lisibilité

Les guides de style divergent, mais la répartition pratique est simple. Utilisez le Title Case où chaque mot est une unité d'emphase : titres d'articles, titres de livres et de films, boutons et courts libellés de menu. Utilisez la sentence case pour tout ce que quelqu'un lit comme de la prose : texte courant, descriptions, messages d'erreur, info-bulles.

Le raisonnement concerne la façon dont l'œil se déplace. Dans un titre de cinq mots, mettre une majuscule à chaque mot aide le lecteur à le analyser comme un titre. Dans un paragraphe, des majuscules sur chaque mot interrompent le flux et donnent un effet criard ou formel, l'équivalent visuel de quelqu'un qui parle trop fort.

Les guides de style divergent aussi sur les petits mots : la plupart ne mettent une majuscule qu'aux mots de plus de trois ou quatre lettres, donc « the » et « in » restent en minuscules dans un titre. Les convertisseurs de Title Case automatisés mettent généralement une majuscule à tout, c'est pourquoi un titre généré a souvent besoin d'une vérification rapide par rapport au style que vous suivez.

Si vous ne devez retenir qu'une règle : la cohérence bat la justesse de n'importe quel style particulier. Une page qui mélange des titres en Title Case et en sentence case paraît cassée même quand chaque titre individuel est défendable.

Convertir la casse sans devinettes

Quel que soit le style dont vous avez besoin, la conversion devrait être à un seul collage :

• Un convertisseur de casse gratuit couvrant UPPERCASE, lowercase, Title Case, sentence case, camelCase, snake_case et plus.
• Gère le texte multi-lignes, donc une colonne entière se convertit en un seul collage.
• Fonctionne entièrement dans votre navigateur — rien de ce que vous collez n'est téléversé.
• Fait partie de l'ensemble plus large de string tools : compteur de mots, compteur de caractères, encodeur d'URL et encodeur Base64.

Questions fréquentes