Une valeur comme "42" ressemble à un nombre, mais un programme la traite d’abord comme du texte. Cette différence devient importante dès qu’il faut additionner, comparer ou contrôler une saisie. C’est le besoin généralement résumé par l’expression convert string to int, avec des méthodes qui varient selon Python, JavaScript, Java ou C#.
La conversion dépend du langage et de la qualité de la saisie
-
Python utilise
int()et lève une erreur si le texte n’est pas valide. -
JavaScript propose
parseInt(),Number()etBigInt()selon le besoin. -
Java s’appuie sur
Integer.parseInt()avec une exception en cas d’échec. -
C# privilégie souvent
int.TryParse()pour valider une saisie sans interrompre le programme. - Une chaîne contenant des espaces, décimales ou séparateurs français demande un traitement spécifique.
Pourquoi une chaîne numérique doit-elle être convertie
Les données reçues depuis un formulaire, une API, un fichier CSV ou une ligne de commande arrivent très souvent sous forme de texte. Même "18" et 18 affichent la même valeur à l’écran, ils n’ont pas le même type et ne produisent pas toujours le même résultat dans une opération.
age = "18"
# Incorrect ou imprévisible selon le langage
resultat = age + 2
# Après conversion
age_entier = int(age)
resultat = age_entier + 2
Je distingue toujours deux étapes dans ce traitement. La première consiste à interpréter le texte comme un nombre. La seconde consiste à décider quoi faire si le contenu est vide, négatif, trop grand ou simplement invalide.
Une conversion réussie doit donc respecter le format attendu. "42", "-7" et parfois " 42 " sont acceptables, tandis que "42,5", "vingt" ou "12 euros" nécessitent une règle supplémentaire.
Les méthodes essentielles selon le langage
Python avec int
En Python, la solution directe est int(). Elle accepte notamment les signes, les espaces autour du nombre et une base précisée explicitement. La documentation Python indique aussi qu’une conversion impossible déclenche une exception ValueError. La documentation officielle de Python détaille ces règles.
texte = " -27 "
nombre = int(texte)
print(nombre) # -27
print(type(nombre)) #
Pour une donnée utilisateur, je préfère entourer la conversion d’un contrôle d’erreur. Cela évite qu’une seule valeur mal saisie fasse tomber tout le programme.
texte = input("Entrez un nombre entier : ")
try:
nombre = int(texte)
print(f"Valeur acceptée : {nombre}")
except ValueError:
print("Veuillez saisir un entier valide.")
JavaScript avec parseInt ou Number
En JavaScript, parseInt(texte, 10) convient lorsque l’on veut lire un entier dans une chaîne. Je recommande de préciser la base 10, car le deuxième argument rend l’intention claire et évite les mauvaises interprétations dans du code ancien ou réutilisé.
const texte = "42";
const nombre = Number.parseInt(texte, 10);
console.log(nombre); // 42
Attention, parseInt("42px", 10) renvoie 42. Ce comportement peut être pratique pour analyser une valeur CSS, mais il est risqué pour valider un formulaire. Pour exiger que toute la chaîne soit numérique, Number() est souvent plus strict. MDN rappelle également que JavaScript utilise principalement le type Number et non un type entier séparé. La référence MDN sur parseInt présente les règles de lecture et les cas retournant NaN.
Number("42") // 42
Number("42px") // NaN
Number("42.5") // 42.5
Number.parseInt("42.5", 10) // 42
Pour les entiers très grands, je ne m’appuie pas aveuglément sur Number. Au-delà de 9 007 199 254 740 991, la précision entière sûre de JavaScript est dépassée. Dans ce cas, BigInt("9007199254740992") est plus adapté, à condition que les opérations du projet soient compatibles.
Java avec Integer.parseInt
En Java, la méthode courante est Integer.parseInt(). Elle renvoie un type primitif int, limité à une valeur comprise entre -2 147 483 648 et 2 147 483 647.
String texte = "123";
int nombre = Integer.parseInt(texte);
System.out.println(nombre + 7); // 130
Une valeur mal formée ou trop grande provoque une NumberFormatException. Je traite donc cette exception lorsque la chaîne provient d’une source que le programme ne contrôle pas.
try {
int nombre = Integer.parseInt(texte);
System.out.println(nombre);
} catch (NumberFormatException erreur) {
System.out.println("Nombre entier invalide");
}
Lire aussi : Taille tableau C - Évitez les erreurs courantes et codez mieux
C# avec int.Parse ou int.TryParse
En C#, int.Parse() ressemble à la solution Java, mais int.TryParse() est souvent préférable pour une saisie utilisateur. La méthode renvoie true ou false et évite de gérer une exception dans le parcours normal du formulaire.
string texte = "256";
if (int.TryParse(texte, out int nombre))
{
Console.WriteLine(nombre);
}
else
{
Console.WriteLine("Valeur invalide");
}
Microsoft recommande justement Parse ou TryParse selon le niveau de contrôle nécessaire. Pour une donnée externe, mon choix va presque toujours à TryParse, plus lisible dans une logique de validation.
Comment gérer les espaces, les décimales et les formats locaux
Le cas simple "123" ne pose presque jamais de problème. Les difficultés apparaissent avec les données réelles, par exemple " 123 ", "1 234", "12,5" ou "1.000". Avant de convertir, il faut savoir si le séparateur représente des milliers ou une partie décimale.
Un entier ne doit pas être utilisé pour tronquer silencieusement une décimale. En Python, int("12.5") échoue, ce qui est sain. En JavaScript, parseInt("12.5", 10) donne 12, ce qui peut masquer une erreur métier.
const texte = "12.5";
const valeur = Number(texte);
if (Number.isInteger(valeur)) {
console.log("Entier valide");
} else {
console.log("La valeur contient une partie décimale");
}
Pour un formulaire français, je normalise explicitement les séparateurs avant toute conversion. Cette étape doit rester liée au format attendu, car remplacer systématiquement les virgules par des points peut transformer une valeur mal saisie en résultat trompeur.
const saisie = "1 250".replace(/\s/g, "");
const nombre = Number.parseInt(saisie, 10);
console.log(nombre); // 1250
Dans un contexte financier, je déconseille de convertir directement un montant en entier sans règle métier claire. Un prix comme "12,50" représente généralement un nombre décimal, pas l’entier 12. Il faut alors utiliser un type décimal ou stocker les centimes sous forme d’entier après une validation rigoureuse.
Les bases numériques ne se limitent pas au système décimal
La base 10 est celle des saisies ordinaires, mais les développeurs manipulent aussi des valeurs binaires, octales et hexadécimales. La conversion doit alors recevoir la base correcte, sinon le programme lira les chiffres avec une mauvaise interprétation.
# Python
binaire = int("1010", 2) # 10
hexadecimal = int("FF", 16) # 255
// JavaScript
const binaire = Number.parseInt("1010", 2); // 10
const hexadecimal = Number.parseInt("FF", 16); // 255
Le piège le plus fréquent est d’oublier le paramètre de base avec parseInt(). Pour une valeur provenant d’un protocole, d’un fichier technique ou d’un système embarqué, je préfère toujours écrire la base explicitement. Le code devient immédiatement compréhensible et plus facile à relire.
Il faut aussi distinguer la conversion d’une chaîne entière de la conversion d’un nombre flottant. Si le texte contient une valeur comme "3.99", décider de produire 3 revient à appliquer une troncature, pas à effectuer une conversion neutre.
Éviter les erreurs de validation et de dépassement
Une conversion techniquement réussie ne garantit pas que la donnée soit acceptable pour l’application. "0" est un entier valide, mais il peut être interdit pour une quantité, un âge ou un identifiant. Après la conversion, j’applique donc toujours les règles métier.
texte = "17"
try:
age = int(texte)
if 0 <= age <= 120:
print("Âge accepté")
else:
print("Âge hors limites")
except ValueError:
print("Format invalide")
Le dépassement de capacité est un autre point souvent oublié. Un type int limité sur 32 bits ne peut pas stocker n’importe quelle valeur. En Java, C# et de nombreux langages typés, il faut choisir long, Int64 ou un type arbitraire si les identifiants ou compteurs dépassent cette plage.
Je vérifie également les valeurs nulles et vides avant d’appeler la fonction de conversion. Une chaîne absente n’est pas toujours équivalente à zéro, et faire cette substitution automatiquement peut créer des erreurs difficiles à repérer.
- Chaîne vide : demander une valeur ou appliquer une valeur par défaut documentée.
- Espaces seuls : considérer la saisie comme vide après nettoyage.
- Texte partiellement numérique : le rejeter si toute la chaîne doit être valide.
- Nombre trop grand : utiliser un type plus large ou signaler l’erreur.
- Valeur négative : l’accepter uniquement si le domaine métier l’autorise.
Cette discipline est particulièrement importante pour les données reçues par une API. Une valeur contrôlée côté interface peut tout de même être modifiée manuellement ou envoyée directement au serveur. La validation finale doit donc toujours être réalisée côté backend.
Choisir la bonne méthode selon le cas réel
| Situation | Méthode recommandée | Point de vigilance |
|---|---|---|
| Texte déjà contrôlé |
int(), parseInt() ou Parse()
|
Une erreur peut interrompre le programme |
| Saisie utilisateur |
TryParse() ou gestion d’exception |
Prévoir un message d’erreur clair |
| Valeur avec décimales | Type flottant ou décimal | Ne pas tronquer automatiquement |
| Valeur hexadécimale ou binaire | Conversion avec base explicite | Vérifier le préfixe et le format |
| Entier très grand en JavaScript | BigInt() |
Ne pas mélanger directement avec Number
|
Mon approche est simple. Je choisis d’abord le type qui correspond réellement à la donnée, puis je valide le format, la plage et les règles métier. La fonction de conversion n’est qu’une étape du traitement, pas une garantie de qualité à elle seule.
Une conversion fiable commence avant l’appel à int
Pour une donnée sûre et courte, la conversion directe suffit. Dès qu’elle vient d’un utilisateur, d’un fichier ou d’un service externe, ajoutez un nettoyage maîtrisé, gérez l’échec et contrôlez les limites.
Le bon réflexe consiste à différencier texte numérique, entier valide et valeur acceptable pour l’application. Cette distinction évite les résultats silencieusement faux et rend le code plus robuste, quel que soit le langage utilisé.