Conversion binaire, octale, décimale et hexadécimale

Les quatre bases courantes

En base 2, chaque position correspond à une puissance de 2. Ainsi, 1101 vaut :

• 1 × 2³ = 8 ;
• 1 × 2² = 4 ;
• 0 × 2¹ = 0 ;
• 1 × 2⁰ = 1.

On additionne : 8 + 4 + 0 + 1 = 13. On peut donc écrire 1101₂ = 13₁₀. Les indices ne sont pas toujours affichés dans les outils, mais ici ils évitent toute ambiguïté.

En base 8, les positions valent des puissances de 8. En base 16, ce sont des puissances de 16. Comme il faut coder seize valeurs avec un seul symbole, l'hexadécimal utilise A à F : A vaut 10, B vaut 11, jusqu'à F qui vaut 15.

Même valeur, écritures différentes

Changer de base ne change pas la valeur de l'objet : ça change seulement la façon de l'écrire. Quelques équivalences :

Attention à une confusion classique : croire que 10 « signifie toujours dix ». En base 2, 10₂ vaut 2 en décimal. En base 8, 10₈ vaut 8. Le contexte (ou un préfixe en code) dit comment lire les chiffres.

D'une base quelconque vers le décimal

On prend chaque chiffre, on le multiplie par la puissance de la base correspondant à sa position, puis on additionne. La position la plus à droite correspond à la puissance 0.

Pour convertir 101101₂ en décimal :

1 × 2⁵ + 0 × 2⁴ + 1 × 2³ + 1 × 2² + 0 × 2¹ + 1 × 2⁰

On obtient 32 + 8 + 4 + 1 = 45. Les zéros ne changent rien à la somme, mais ils indiquent bien où se trouvent les autres chiffres : enlever un zéro au milieu modifierait la valeur.

Même idée en hexadécimal. Pour 2D₁₆, D vaut 13 :

2 × 16¹ + 13 × 16⁰ = 32 + 13 = 45.

Donc 2D₁₆ et 101101₂ représentent tous les deux la valeur 45₁₀.

Du décimal vers une autre base : divisions successives

Pour convertir un entier décimal vers une base cible, on divise par cette base et on récupère le reste. On recommence avec le quotient, jusqu'à obtenir 0. Ensuite, on lit les restes en remontant dans l'ordre inverse.

Convertissons 45 en binaire :

En lisant les restes de bas en haut, on obtient 101101. Donc 45 (en base 10) devient 101101 (en base 2).

Pour 255 en hexadécimal, on divise par 16 :

• 255 ÷ 16 : quotient 15, reste 15 ;
• 15 ÷ 16 : quotient 0, reste 15.

Le reste 15 correspond à F. En ordre inverse des restes, on obtient FF. Donc 255₁₀ = FF₁₆.

La méthode marche aussi pour l'octal : divisez par 8, puis interprétez chaque reste comme un chiffre entre 0 et 7. À la main, c'est utile pour vérifier ; dans du code, un outil ou une fonction dédiée évite surtout les erreurs de calcul.

Conversion directe entre binaire, octal et hexadécimal

L'octal et l'hexadécimal sont pratiques parce qu'ils correspondent à des regroupements réguliers de bits : un chiffre octal représente 3 bits, et un chiffre hexadécimal représente 4 bits. Du coup, vous pouvez souvent éviter de passer par le décimal.

Pour convertir 101101₂ en hexadécimal, regroupez les bits par quatre à partir de la droite : 0010 1101. Le zéro ajouté à gauche ne change pas la valeur. 0010 vaut 2, et 1101 vaut D, donc résultat 2D₁₆.

Pour l'octal, regroupez par trois : 101 101. Chaque groupe vaut 5, donc 101101₂ = 55₈.

Le détail important : on complète seulement le groupe de gauche avec des zéros si besoin. Ajouter des zéros à droite ne donnera pas la même valeur.

Le binaire : bits, masques et représentation des données

En binaire, vous raisonnez directement sur les bits. C'est utile pour comprendre des opérations binaires, des indicateurs regroupés dans un entier, ou certains protocoles.

Un exemple parlant : un masque peut activer ou désactiver des options en associant chaque option à une position. Concrètement, si vous comprenez comment lire quelques bits, vous comprenez aussi pourquoi un décalage ou un masque produit tel résultat.

Dans le quotidien, vous n'avez pas besoin de convertir « à la main » chaque donnée : les outils et les langages le font. Mais lire la logique de base aide, surtout quand on doit relier une valeur numérique à ce qu'elle signifie réellement.

L'hexadécimal : une écriture compacte des octets

Un chiffre hexadécimal correspond exactement à 4 bits. Un octet contient 8 bits, donc il s'écrit avec deux chiffres hexadécimaux. Par exemple, 11111111₂ vaut FF₁₆, ce qui fait 255 en décimal (et c'est bien la valeur maximale sur un octet non signé).

Cette correspondance explique pourquoi l'hexadécimal est courant :

• pour voir des valeurs d'octets et certaines données en mémoire ;
• pour les couleurs Web, comme #4338ca ;
• pour des adresses et des identifiants techniques ;
• dans les sorties de débogage et les affichages de données.

Une couleur comme #4338ca contient trois paires hexadécimales : 43, 38 et ca, qui correspondent aux composantes rouge, verte et bleue en notation RGB. Converties en décimal : 67, 56 et 202. L'hexadécimal est compact, mais il ne « rend pas » la couleur plus précise : il reflète juste la valeur sous-jacente.

L'octal : un cas d'usage qui reste concret

L'octal est moins fréquent dans les interfaces modernes, mais on le croise encore, notamment pour les permissions Unix et Linux. Avec chmod 755, les trois chiffres décrivent les droits du propriétaire, du groupe et des autres :

• 7 : lecture, écriture et exécution ;
• 5 : lecture et exécution.

Donc 755 revient à : propriétaire rwx, groupe r-x, autres r-x.

Chaque chiffre est une somme de valeurs : lecture = 4, écriture = 2, exécution = 1. Ainsi, 7 = 4 + 2 + 1, et 5 = 4 + 1. On comprend donc 755 sans avoir à le traiter comme une formule mystérieuse.

Petite mise en garde : les permissions effectives dépendent aussi du contexte (système de fichiers, propriétaire, parfois options de montage). Les bits spéciaux (setuid, sticky bit) ajoutent d'autres nuances. Si c'est une question de sécurité, vérifiez toujours les droits effectifs plutôt que de vous contenter du nombre affiché.

Reconnaître les préfixes usuels

Dans beaucoup de langages, ces notations reviennent :

• 0b1010 pour le binaire ;
• 0o12 pour l'octal ;
• 0xFF pour l'hexadécimal.

Sans préfixe, l'interprétation n'est pas garantie. Certains vieux langages ou contextes utilisent un zéro initial pour signaler l'octal, mais c'est ambigu (ou absent) selon le cas. Pour du code moderne, utilisez la syntaxe explicitement documentée.

En JavaScript, parseInt('ff', 16) lit la chaîne comme une valeur en base 16 et renvoie 255. (255).toString(2) produit 11111111. En Python, int('ff', 16) renvoie aussi 255, et bin(255), oct(255) et hex(255) renvoient respectivement des représentations préfixées.

Pour les détails propres à chaque langage, appuyez-vous sur la documentation officielle : MDN sur parseInt en JavaScript et la documentation Python sur les fonctions intégrées.

Vérifier les limites de la représentation

Une conversion « mathématiquement correcte » ne veut pas dire « valide dans votre contexte ». Avant de convertir, vérifiez au minimum :

1. La base attendue. 10 n'a pas la même valeur en base 2, 8 ou 10.
2. Les caractères autorisés. G n'est pas un chiffre hexadécimal ; 8 n'est pas un chiffre octal.
3. La taille du type. Un entier stocké sur un nombre limité de bits ne peut pas représenter toutes les valeurs.
4. Signé ou non signé. Les mêmes bits peuvent donner des résultats différents selon l'interprétation.
5. Les règles du langage. Une chaîne mal formée peut provoquer une erreur, renvoyer une valeur spéciale ou être interprétée partiellement selon la fonction.

En JavaScript, les nombres ordinaires utilisent le type Number (flottant), ce qui limite la précision entière pour de très grandes valeurs. Pour ces cas, on regarde les limites du type et, si le besoin s'y prête, on utilise BigInt. En Python, les entiers peuvent grossir au-delà d'une taille fixe en mémoire, mais les formats d'entrée/sortie et les protocoles imposent souvent leurs propres limites.

Nombres négatifs et complément à deux

Pour les entiers négatifs, les ordinateurs utilisent le plus souvent le complément à deux, sur une largeur fixée (par exemple 8, 16, 32 bits, etc.). Du coup, le motif de bits dépend à la fois de la valeur et du nombre de bits retenus.

Sur 8 bits, 00000101 représente 5. Le motif 11111011 peut représenter -5 si on l'interprète comme un entier signé en complément à deux. En revanche, interprété comme un entier non signé sur 8 bits, ce même motif vaut 251. Les bits ne changent pas : seule l'interprétation change.

C'est pour ça qu'on ne peut pas toujours déduire une conversion négative en « ajoutant un signe moins » à une écriture binaire. Quand vous lisez une valeur provenant d'un fichier, d'une API ou d'un registre, identifiez le type, la largeur et le caractère signé avant de conclure. Dans un protocole, ce sont des éléments du format, pas des détails optionnels.

Une méthode de vérification simple

Quand vous faites un calcul à la main (ou que vous voulez valider rapidement du code), une vérification croisée évite pas mal de bêtises : convertissez dans l'autre base, puis revenez à la valeur de départ.

Par exemple, si vous trouvez FF pour 255, vérifiez que F × 16 + F vaut bien 15 × 16 + 15, donc 255.

Et si vous manipulez des données destinées à tourner en production, ajoutez des tests : zéro, valeur maximale du type, valeur invalide, et, si nécessaire, cas négatifs. Une conversion « une fois pour comprendre » est simple. La répéter sur des entrées non contrôlées sans validation, c'est là que les ennuis commencent.