Conversion de température : Celsius, Fahrenheit, Kelvin

Lundi, vous mettez en production un tableau de bord météo. Mercredi, un utilisateur de Toronto ouvre un ticket : l’appli affiche la température extérieure comme 284. Le endpoint OpenWeatherMap a renvoyé des Kelvin (format par défaut), l’interface attendait des Celsius, et entre les deux personne n’a pris la peine de vérifier. Une soustraction oubliée, une capture d’écran virale sur Twitter.

Si vous avez juste besoin des deux formules et que vous voulez passer à autre chose :

Formule Celsius vers Fahrenheit : °F = °C × 9/5 + 32
Formule Fahrenheit vers Celsius : °C = (°F − 32) × 5/9
Celsius vers Kelvin : K = °C + 273.15

Ces trois formules couvrent environ 90 % des besoins réels des développeurs. Le reste de ce guide s’attaque aux 10 % restants : d’où vient le 9/5, pourquoi le Kelvin n’est jamais négatif, comment faire rejeter celsiusToFahrenheit(kelvinValue) à la compilation par le système de types, et comment ne plus jamais livrer le bug de Toronto. Sinon, sautez la lecture et passez directement par notre convertisseur de température quand il faut juste un chiffre tout de suite. Pour les unités hors température, voir le guide complet de conversion d’unités.

Pourquoi la température se distingue des autres conversions d’unités

La plupart des conversions d’unités sont trivialement linéaires en passant par zéro. Un mètre vaut 3,28084 pieds, point final. Doublez les mètres, doublez les pieds. Zéro mètre égale zéro pied. On peut construire une bibliothèque de conversion avec une seule constante multiplicative par paire et ne plus jamais y repenser.

La température rompt ce modèle sur un point clé : ses échelles ne partagent pas de point zéro. Le Celsius ancre son zéro au point de congélation de l’eau. Le Fahrenheit à un mélange saumuré de 1724. Le Kelvin au plancher théorique de la thermodynamique. Passer de l’une à l’autre demande à la fois un facteur d’échelle et un décalage — la température est une transformation affine, pas linéaire.

Conséquence concrète et dangereuse : les valeurs de température ne sont pas additives comme le sont les longueurs ou les masses. 20°C + 20°C n’est pas 40°C au sens physique. On ne peut pas « additionner deux pièces » pour obtenir une pièce plus chaude. On peut en revanche ajouter une différence de température à une température, parce que les différences, elles, sont linéaires. C’est cette distinction qui a causé l’incident Medeva de 2006 au Royaume-Uni, où un enregistreur de chaîne du froid pharmaceutique a confondu une lecture absolue avec un delta et a étiqueté des milliers de doses comme hors spécification. Les grandeurs intensives comme la température réclament toujours ce garde-fou mental : des nombres qui partagent une unité ne partagent pas automatiquement la même algèbre.

Les quatre échelles de température expliquées

Deux échelles suffisent pour le code quotidien (Celsius, Fahrenheit), une troisième compte pour tout ce qui touche au scientifique (Kelvin), et la quatrième n’apparaît qu’à un seul endroit : les manuels américains de thermodynamique et les bases de code CVC qui les référencent encore.

Celsius (°C)

Anders Celsius a publié son échelle en 1742, initialement avec 0° à l’ébullition et 100° au gel — l’inverse de l’usage actuel. L’orientation moderne, avec 0°C au point de congélation de l’eau et 100°C à son point d’ébullition sous une atmosphère standard, est apparue peu après sa mort. C’est aujourd’hui l’unité dérivée du SI pour la température courante et l’échelle par défaut dans tous les pays sauf les États-Unis, les Bahamas, le Belize, les îles Caïmans et le Liberia.

La redéfinition du SI en 2019 a rattaché rigoureusement le Celsius au Kelvin : 0°C vaut désormais exactement 273,15 K. Le point de congélation de l’eau, autrefois la définition, est maintenant une conséquence mesurée (il tombe sur 0°C à quelques parties par million près, mais ce n’est plus l’ancre).

Fahrenheit (°F)

Daniel Gabriel Fahrenheit a proposé son échelle en 1724. Il a choisi 0°F comme point de congélation d’un mélange saumuré précis — la température la plus basse qu’il pouvait reproduire de façon fiable lors d’un hiver à Dantzig — et 96°F comme température corporelle. Un recalibrage ultérieur sur les points de congélation et d’ébullition de l’eau pure a porté la température corporelle à 98,6°F et placé la congélation à 32°F et l’ébullition à 212°F, soit un intervalle de 180 degrés.

Le Fahrenheit perdure aux États-Unis pour la météo, la cuisine et l’usage médical. L’intervalle de 180 degrés entre congélation et ébullition (contre 100 en Celsius) est parfois défendu comme offrant « une résolution plus fine pour les températures ambiantes » — argument marginal, qui explique toutefois pourquoi les thermostats américains sont gradués par pas de 1°F tandis que les européens utilisent couramment des pas de 0,5°C.

Kelvin (K)

William Thomson, Lord Kelvin, a proposé une échelle absolue en 1848. Le Kelvin moderne est l’unité de base SI de la température. La redéfinition du SI en 2019 a rattaché le kelvin à la constante de Boltzmann k_B = 1.380649 × 10⁻²³ J/K exactement, en faisant une grandeur définie plutôt que mesurée.

Le Kelvin présente trois particularités à connaître :

Pas de symbole degré. On écrit 300 K, pas 300°K. Convention SI depuis 1967.
Commence au zéro absolu. 0 K = −273,15°C. Une valeur Kelvin négative ne devrait jamais apparaître dans des données valides ; traitez-la comme une erreur d’entrée.
Même taille de degré que le Celsius. Une variation de 1 K équivaut à une variation de 1°C. Les différences de température sont interchangeables entre les deux ; seules les valeurs absolues diffèrent du décalage de 273,15.

Le Kelvin est le bon choix dès qu’on multiplie ou divise des températures — rayonnement thermique (T⁴), loi des gaz parfaits, physique du corps noir. Une division par une valeur Celsius négative ou proche de zéro fait exploser une physique qu’on veut presque toujours garder finie.

Rankine (°R)

William Rankine a proposé cette échelle en 1859 comme équivalent Fahrenheit du Kelvin : une échelle absolue, zéro au zéro absolu, mais avec des degrés de la taille Fahrenheit. 0°R = −459,67°F. 491,67°R = 0°C.

On ne croise presque jamais le Rankine en dehors de l’ingénierie thermodynamique américaine — calculs CVC, raffinage pétrolier, analyse de combustion des moteurs-fusées — où les calculs exigent une échelle absolue alors que les données d’entrée arrivent en Fahrenheit. La conversion est mécanique : °R = °F + 459,67, ou de façon équivalente °R = K × 9/5. La plupart des logiciels d’ingénierie modernes peuvent rester en Kelvin en interne et ne convertir que pour l’affichage — c’est ce que je recommande quand on a le choix.

Formules de conversion de température (les six directions)

Six directions, quatre échelles, six formules. En pratique, on retient celles qui passent par le Celsius et on compose le reste.

Celsius vers Fahrenheit et inversement

°F = °C × 9/5 + 32
°C = (°F − 32) × 5/9

Le facteur 9/5 est le rapport entre les intervalles des deux échelles pour les mêmes repères physiques. De la congélation à l’ébullition, le Fahrenheit couvre 180 degrés (32 à 212), le Celsius 100 (0 à 100). 180 / 100 = 9/5 = 1,8. Le + 32 est le décalage qui aligne les zéros des points de congélation, puisque le zéro Fahrenheit se situe 32°F sous le zéro Celsius.

Exemple détaillé : °F = 25 × 9/5 + 32 = 45 + 32 = 77°F.

Celsius vers Kelvin et inversement

K = °C + 273.15
°C = K − 273.15

Pas de mise à l’échelle, juste un décalage. 273,15 est la distance numérique entre le zéro Celsius (point de congélation de l’eau) et le zéro absolu, mesurée en degrés Celsius. Kelvin et Celsius partagent la même taille de degré, d’où l’absence de multiplicateur.

Fahrenheit vers Kelvin et inversement

K = (°F − 32) × 5/9 + 273.15
°F = (K − 273.15) × 9/5 + 32

Pas de forme plus courte — il faut à la fois un changement d’échelle et un changement de décalage. Dans le code, il est presque toujours plus propre de passer par le Celsius : k = cToK(fToC(f)). Moins de lignes, plus de confiance, et le compilateur optimise la composition de toute façon.

Conversions Rankine

°R = °F + 459.67
°F = °R − 459.67
°R = K × 9/5
K  = °R × 5/9
°R = °C × 9/5 + 491.67

491,67 vaut 32 × 9/5 + 459,67, soit la valeur Rankine correspondant à 0°C. Ces formules, on les compose rarement en pratique. Quand le Rankine devient nécessaire, traitez-le comme « le jumeau absolu du Fahrenheit » et passez par le Fahrenheit ou le Kelvin.

D’où vient le 9/5 ? Une dérivation rapide

Les deux échelles sont reliées par une fonction affine °F = a × °C + b. Pour résoudre a et b, il faut deux points de calibrage connus. La congélation et l’ébullition font la paire conventionnelle :

Congélation : 0°C ↔ 32°F
Ébullition : 100°C ↔ 212°F

Injectez les deux dans °F = a × °C + b :

32  = a × 0   + b   →  b = 32
212 = a × 100 + 32  →  a = (212 − 32) / 100 = 180 / 100 = 9/5

Et voilà — deux équations linéaires, deux inconnues, toute la conversion en découle. L’intuition géométrique : imaginez deux thermomètres verticaux côte à côte, l’un en Celsius, l’autre en Fahrenheit. Le thermomètre Fahrenheit est étiré verticalement (pente 9/5) et décalé vers le haut (ordonnée à l’origine 32) par rapport au Celsius. Toute autre valeur de conversion tombe sur cette droite étirée-et-décalée.

La même dérivation avec (0°C, 273,15 K) et (100°C, 373,15 K) donne Celsius vers Kelvin : pente 1, ordonnée 273,15. Avec deux points de calibrage non ambigus, on obtient n’importe quelle conversion affine. Rien de mathématiquement spécial dans la température — toute la complexité tient dans cette configuration à deux ancres que les autres types d’unités n’exigent pas.

Le point d’intersection à −40° : un moyen mnémotechnique utile

Existe-t-il une température où Celsius et Fahrenheit donnent la même valeur ? On pose °C = °F dans la formule de conversion :

°C = °C × 9/5 + 32
°C − °C × 9/5 = 32
°C × (1 − 9/5) = 32
°C × (−4/5) = 32
°C = −40

Donc −40°C = −40°F. Un unique point de croisement, qui correspond à une température bien réelle à Yellowknife, Iakoutsk ou Fairbanks en janvier. Aussi une vérification mentale rapide : chaque fois qu’on évalue à vue une conversion C↔F et que le résultat tombe près de −40, les deux nombres doivent être proches l’un de l’autre. Si l’un dit −40°C et l’autre −72°F, il y a un bug de direction.

Je garde la liste complète des repères collée à côté de mon écran : congélation (0 / 32), température corporelle (37 / 98,6), température ambiante (20 / 68), ébullition (100 / 212), −40 (−40 / −40). Cinq points couvrent presque toutes les vérifications de bon sens dont j’ai besoin.

Conversion de température dans le code

Les formules sont triviales. Les écrire correctement dans une base de code réelle tient à deux choses : empêcher un appelant de passer du Fahrenheit là où on attendait du Celsius, et rendre le comportement en virgule flottante prévisible aux frontières (congélation, zéro absolu, températures de four). Chaque exemple qui suit est un programme complet et exécutable.

JavaScript / TypeScript

Le JavaScript vanilla donne des conversions fonctionnelles immédiatement :

const cToF = (c) => c * 9 / 5 + 32;
const fToC = (f) => (f - 32) * 5 / 9;
const cToK = (c) => c + 273.15;
const kToC = (k) => k - 273.15;
const fToK = (f) => cToK(fToC(f));
const kToF = (k) => cToF(kToC(k));
const cToR = (c) => (c + 273.15) * 9 / 5;
const rToC = (r) => r * 5 / 9 - 273.15;

console.log(cToF(100));   // 212
console.log(fToC(98.6));  // 37
console.log(kToC(300));   // 26.85

TypeScript permet de transformer la confusion d’unités en erreur de compilation en « brandant » le type numérique :

type Scale = 'C' | 'F' | 'K' | 'R';
type Temp<S extends Scale> = number & { readonly __scale: S };

const t = <S extends Scale>(value: number, _scale: S): Temp<S> =>
  value as Temp<S>;

const cToF = (c: Temp<'C'>): Temp<'F'> => t(c * 9 / 5 + 32, 'F');
const fToC = (f: Temp<'F'>): Temp<'C'> => t((f - 32) * 5 / 9, 'C');

const indoor = t(22, 'C');
const outdoor = cToF(indoor);   // OK : Temp<'F'>
// const broken = cToF(outdoor); // Erreur de compilation : Temp<'F'> n'est pas Temp<'C'>

Les types brandés ont un coût d’exécution nul et coûtent environ dix lignes de boilerplate. En échange, le bug de Toronto du paragraphe d’ouverture devient une ondulation rouge dans l’éditeur.

Python

De simples fonctions font l’affaire, mais un Enum combiné à un dataclass s’amortit dès la première fois où on journalise une température :

from dataclasses import dataclass
from enum import Enum

class Scale(Enum):
    C = "°C"
    F = "°F"
    K = "K"
    R = "°R"

@dataclass(frozen=True)
class Temperature:
    value: float
    scale: Scale

    def to(self, target: Scale) -> "Temperature":
        c = _to_celsius(self)
        return _from_celsius(c, target)

    def __str__(self) -> str:
        return f"{self.value:.2f}{self.scale.value}"

def _to_celsius(t: Temperature) -> float:
    if t.scale is Scale.C: return t.value
    if t.scale is Scale.F: return (t.value - 32) * 5 / 9
    if t.scale is Scale.K: return t.value - 273.15
    if t.scale is Scale.R: return (t.value - 491.67) * 5 / 9
    raise ValueError(f"Échelle inconnue : {t.scale}")

def _from_celsius(c: float, scale: Scale) -> Temperature:
    if scale is Scale.C: return Temperature(c, scale)
    if scale is Scale.F: return Temperature(c * 9 / 5 + 32, scale)
    if scale is Scale.K: return Temperature(c + 273.15, scale)
    if scale is Scale.R: return Temperature(c * 9 / 5 + 491.67, scale)
    raise ValueError(f"Échelle inconnue : {scale}")

body = Temperature(37, Scale.C)
print(body.to(Scale.F))   # 98.60°F
print(body.to(Scale.K))   # 310.15K

Pour des données scientifiques où 0.1 + 0.2 != 0.3 devient un problème d’audit, remplacez float par decimal.Decimal. Le compromis porte sur la vitesse (Decimal est environ 50 fois plus lent) et sur le fait que 5/9 n’a pas non plus de représentation décimale exacte — il faut donc Decimal(5) / Decimal(9) avec un contexte contrôlé. Pour la plupart des pipelines de capteurs, float plus round(value, 2) à la frontière d’affichage suffit largement.

Go

Le système de types de Go va plus loin que TypeScript : un type float64 nommé ne peut pas être mélangé silencieusement avec un autre type float64 nommé, même s’ils partagent la même représentation à l’exécution.

package main

import "fmt"

type Celsius float64
type Fahrenheit float64
type Kelvin float64
type Rankine float64

func (c Celsius) ToFahrenheit() Fahrenheit { return Fahrenheit(c*9/5 + 32) }
func (c Celsius) ToKelvin() Kelvin         { return Kelvin(c + 273.15) }
func (f Fahrenheit) ToCelsius() Celsius    { return Celsius((f - 32) * 5 / 9) }
func (k Kelvin) ToCelsius() Celsius        { return Celsius(k - 273.15) }
func (f Fahrenheit) ToKelvin() Kelvin      { return f.ToCelsius().ToKelvin() }

func main() {
    room := Celsius(22)
    fmt.Printf("%.2f °F\n", room.ToFahrenheit()) // 71.60 °F
    fmt.Printf("%.2f K\n", room.ToKelvin())      // 295.15 K

    // var bug Fahrenheit = room          // erreur de compilation
    // fmt.Println(room.ToKelvin() + 1)   // erreur de compilation : Kelvin + int non typé nécessite Kelvin(1)
}

Le coût tient à peu près à une ligne par échelle. Le gain : ToFahrenheit ne peut pas accepter une valeur Kelvin par accident, et une fonction qui attend Celsius refuse un float64 brut au site d’appel.

Rust

Le pattern newtype de Rust offre les mêmes garanties que Go, plus des conversions From/Into à coût quasi nul :

#[derive(Clone, Copy, Debug, PartialEq)]
struct Celsius(f64);

#[derive(Clone, Copy, Debug, PartialEq)]
struct Fahrenheit(f64);

#[derive(Clone, Copy, Debug, PartialEq)]
struct Kelvin(f64);

impl From<Celsius> for Fahrenheit {
    fn from(c: Celsius) -> Self { Fahrenheit(c.0 * 9.0 / 5.0 + 32.0) }
}

impl From<Fahrenheit> for Celsius {
    fn from(f: Fahrenheit) -> Self { Celsius((f.0 - 32.0) * 5.0 / 9.0) }
}

impl From<Celsius> for Kelvin {
    fn from(c: Celsius) -> Self { Kelvin(c.0 + 273.15) }
}

impl From<Kelvin> for Celsius {
    fn from(k: Kelvin) -> Self { Celsius(k.0 - 273.15) }
}

fn main() {
    let body = Celsius(37.0);
    let body_f: Fahrenheit = body.into();
    let body_k: Kelvin = body.into();
    println!("{:.2} {:?} {:?}", body.0, body_f, body_k);
    // 37.00 Fahrenheit(98.6) Kelvin(310.15)
}

On peut empiler la validation par-dessus : un TryFrom<f64> for Kelvin qui rejette les valeurs négatives renvoie Result<Kelvin, TemperatureError> et déplace la vérification au moment de la construction. Les états invalides n’atteignent jamais la logique métier.

SQL (PostgreSQL)

Stockez les températures avec des contraintes CHECK et dérivez les unités alternatives comme colonnes générées. Une valeur Kelvin négative devient alors une violation de contrainte à l’insertion, pas un bug silencieux qu’on découvre trois requêtes plus loin.

CREATE OR REPLACE FUNCTION c_to_f(c numeric) RETURNS numeric AS $$
    SELECT c * 9.0 / 5.0 + 32.0;
$$ LANGUAGE SQL IMMUTABLE;

CREATE OR REPLACE FUNCTION c_to_k(c numeric) RETURNS numeric AS $$
    SELECT c + 273.15;
$$ LANGUAGE SQL IMMUTABLE;

CREATE TABLE sensor_readings (
    id          bigserial PRIMARY KEY,
    recorded_at timestamptz NOT NULL DEFAULT now(),
    celsius     numeric(6, 2) NOT NULL,
    fahrenheit  numeric(6, 2) GENERATED ALWAYS AS (c_to_f(celsius)) STORED,
    kelvin      numeric(6, 2) GENERATED ALWAYS AS (c_to_k(celsius)) STORED,
    CONSTRAINT  kelvin_non_negative CHECK (celsius >= -273.15)
);

INSERT INTO sensor_readings (celsius) VALUES (22.5), (0), (100);
SELECT celsius, fahrenheit, kelvin FROM sensor_readings;
-- 22.50 | 72.50  | 295.65
--  0.00 | 32.00  | 273.15
-- 100.00| 212.00 | 373.15

-- Rejeté au moment de l'insertion :
-- INSERT INTO sensor_readings (celsius) VALUES (-300);
-- ERROR: new row for relation "sensor_readings" violates check constraint

GENERATED ALWAYS AS ... STORED échange un peu d’espace disque contre de la vitesse à la requête — on lit la valeur, on ne la recalcule pas. Pour des tables IoT à haut volume, remplacez STORED par une vue si la pression disque pèse plus que la latence de lecture.

Gérer les API météo et IoT

Le bug le plus fréquent en production avec les températures n’est pas une erreur de formule. C’est une incompatibilité d’unité entre ce que renvoie une API et ce qu’affiche l’interface. Tour d’horizon des fournisseurs que les développeurs rencontrent le plus souvent :

OpenWeatherMap renvoie du Kelvin par défaut. Passez units=metric pour du Celsius ou units=imperial pour du Fahrenheit. Détail crucial : oublier le paramètre de requête donne du Kelvin. Des nombres comme 284,15 arrivant dans un champ nommé temp ont piégé assez d’ingénieurs pour mériter un test d’intégration dédié.

Open-Meteo renvoie du Celsius par défaut et accepte temperature_unit=fahrenheit. Pas d’option Kelvin — ce n’est pas une API scientifique.

Tomorrow.io et WeatherAPI défaulent au métrique mais renvoient les deux échelles dans la même réponse sous des clés différentes. Lisez la clé que votre code référence réellement, pas celle d’à côté.

Mon modèle pour toute ingestion météo ou capteur :

type Reading = {
  value: number;
  scale: 'C' | 'F' | 'K';
  source: string;
};

function normalise(raw: Reading): number /* celsius */ {
  switch (raw.scale) {
    case 'C': return raw.value;
    case 'F': return (raw.value - 32) * 5 / 9;
    case 'K': return raw.value - 273.15;
  }
}

// À l'ingestion, chaque lecture porte explicitement son échelle.
// La couche UI ne devine jamais — elle consomme du celsius et formate selon la préférence utilisateur.

Deux règles en découlent :

Chaque frontière d’ingestion enregistre l’échelle source. Pas de nombres nus qui traversent les lignes de module.
La couche d’affichage est le seul endroit qui convertit vers l’unité préférée de l’utilisateur.

La double conversion — où deux couches « normalisent » chacune le nombre — est l’autre bug fréquent. Une équipe backend convertit le Kelvin en Celsius à l’écriture. Une équipe frontend, sans le savoir, applique le même - 273,15 à la lecture. Les utilisateurs voient des températures autour de −251°C. Le correctif, c’est un propriétaire unique de la normalisation, pas plus de tests.

Pour l’IoT, les données brutes des capteurs arrivent souvent sous forme de comptage ADC qu’il faut convertir en température via une courbe de calibrage (pour une thermistance NTC 10 kΩ, cela passe par l’équation de Steinhart–Hart). Les conversions d’échelle de température viennent après, sur la valeur déjà calibrée. Mélanger les deux phases, c’est comme ça qu’on se retrouve avec des nombres qui ressemblent à des températures mais sont faux de 30 %.

Pièges fréquents et comment les éviter

Ces six pièges apparaissent dans de vraies bases de code en production. Passez la vôtre au crible.

Utiliser la mauvaise direction de formule

Symptôme le plus courant : une appli qui affiche 37°C comme fièvre de bébé et la signale critique. Ce qui s’est réellement passé : l’API a renvoyé 37°F, quelqu’un a étiqueté ça celsius parce que le nom de colonne le disait, et la logique du seuil médical a comparé à une échelle Celsius. Pour l’éviter, faites porter l’unité par le type, pas par le nom de variable.

Traiter la température comme extensive

averageTemperature a du sens. sumTemperatures n’en a pas. Si votre SQL d’agrégation contient SUM(temperature_c), quelque chose cloche — vous cherchez probablement AVG ou, dans de rares cas, une métrique intégrée en degrés-jours. La température est une grandeur intensive ; n’additionnez pas deux températures en espérant un résultat sensé.

Arrondi en virgule flottante

(37 * 9 / 5) + 32 en JavaScript donne 98.60000000000001, pas 98.6. Tout langage qui utilise les doubles IEEE 754 se comporte pareil. Options :

Afficher avec .toFixed(2) (ou l’équivalent dans votre langage) et s’arrêter là.
Passer par une bibliothèque décimale (decimal.js, Python Decimal, BigDecimal) pour une précision compatible avec un audit.
Stocker en entiers de déci-degrés (370 au lieu de 37.0) et diviser uniquement à l’affichage.

Pour l’affichage dans une UI, toFixed(2) suffit presque toujours. Pour un système de facturation ou de conformité réglementaire où les erreurs d’arrondi s’accumulent, passez aux décimales.

Kelvin négatif dans la validation d’entrée

Le Kelvin est non négatif par loi physique. Un corps de requête contenant { "tempK": -10 } est toujours invalide. Imposez-le à la frontière — schéma JSON, Pydantic, Zod, contrainte CHECK — pas au fond de la logique métier. La seule exception, les systèmes quantiques à « température absolue négative », n’apparaît dans aucune API grand public ; si elle surgit dans votre domaine, vous le savez déjà.

Étiquettes d’unités manquantes dans l’UI et les logs

Une ligne de log qui dit sensor 42: 37 est inutile six mois plus tard. Celsius ? Fahrenheit ? Un comptage ADC brut ? Écrivez toujours sensor 42: 37°C, ou structurez le log en { "sensor": 42, "value": 37, "unit": "celsius" }. L’espace disque est bon marché ; le triage de production à trois heures du matin ne l’est pas.

Confusion entre fuseau horaire et température

Les applis de voyage livrent parfois ce bug : quand un utilisateur change de fuseau horaire, le code décale obligeamment tous les champs horodatés — y compris les lectures de température. La température se moque des fuseaux horaires. C’est l’horodatage d’une lecture qui a besoin de logique de fuseau, pas la valeur lue. Gardez-les dans des champs séparés, et faites-les passer par des pipelines de conversion distincts.

Raccourcis de calcul mental

Pour les moments sans convertisseur ouvert.

Celsius vers Fahrenheit (approximatif) : doublez, ajoutez 30. 20°C → 70°F (réel 68). 30°C → 90°F (réel 86). Précis à 2–3°F près entre 0 et 40°C, ce qui couvre presque toutes les températures qu’on rencontre hors d’un four de céramiste.

Fahrenheit vers Celsius (approximatif) : soustrayez 30, divisez par deux. 80°F → 25°C (réel 26,7). 60°F → 15°C (réel 15,6). Même plage de précision.

Celsius vers Kelvin : ajoutez 273 et arrondissez. La perte de 0,15 K est sous la précision des thermomètres pour tout ce qui se fait hors d’un labo de physique.

Deux ancres à retenir : 20°C = 68°F ≈ 293 K, et 100°C = 212°F = 373,15 K. À partir de là, l’interpolation linéaire suffit pour toute estimation.

Ces règles rapides couvrent le voyage, les approximations en cuisine et la météo. Pour tout ce qui entre dans du code ou un dépôt réglementaire, passez par les formules exactes — ou ouvrez notre outil gratuit de conversion de température et copiez la valeur précise.

Tableaux de référence

Températures du quotidien

Contexte	Celsius	Fahrenheit	Kelvin
Congélateur domestique	−18°C	0°F	255,15 K
Point de congélation	0°C	32°F	273,15 K
Réfrigérateur	4°C	39°F	277,15 K
Température ambiante	20°C	68°F	293,15 K
Température corporelle	37°C	98,6°F	310,15 K
Seuil de fièvre	38°C	100,4°F	311,15 K
Journée d’été chaude	35°C	95°F	308,15 K
Ébullition de l’eau	100°C	212°F	373,15 K

Conversions pour la cuisine et le four

Préréglage four	Celsius	Fahrenheit
Cuisson basse / lente	125°C	257°F
Cuisson douce	150°C	302°F
Cuisson modérée	175°C	347°F
Cuisson standard (gâteaux)	180°C	356°F
Rôtissage	190°C	374°F
Rôtissage chaud	200°C	392°F
Rôtissage vif	220°C	428°F
Pizza / croûte de pain	250°C	482°F

Les recettes américaines arrondissent 350°F à 175°C ou 180°C selon le livre de cuisine ; la valeur exacte est 176,67°C. Les deux choix marchent — les fours domestiques maintiennent rarement mieux que ±5°C de toute façon.

Extrêmes scientifiques

Phénomène	Kelvin	Celsius
Zéro absolu (plancher théorique)	0 K	−273,15°C
Fond diffus cosmologique	2,725 K	−270,425°C
Hélium liquide (ébullition, 1 atm)	4,2 K	−268,95°C
Transition supraconductrice (YBCO)	93 K	−180,15°C
Azote liquide (ébullition)	77 K	−196,15°C
Ombre de l’espace profond	~40 K	~−233°C
Glace sèche (sublimation)	194,65 K	−78,5°C
Surface du Soleil	5 778 K	5 504,85°C
Cœur du Soleil	1,57×10⁷ K	1,57×10⁷ °C*
Plasma de tokamak (cible ITER)	1,5×10⁸ K	~1,5×10⁸ °C*

*À ces ordres de grandeur, le décalage de 273,15 K est une erreur d’arrondi — Celsius et Kelvin se lisent de façon effectivement identique.

FAQ

Quelle est la formule pour convertir le Celsius en Fahrenheit ?

Multipliez le Celsius par 9/5 (ou 1,8), puis ajoutez 32 : °F = °C × 9/5 + 32. Exemple : 25°C × 1,8 + 32 = 77°F. Le multiplicateur reflète le rapport 180:100 entre les intervalles des deux échelles de la congélation à l’ébullition, et le 32 aligne leurs points zéro différents.

Quelle est la formule pour convertir le Fahrenheit en Celsius ?

Soustrayez 32 à la valeur Fahrenheit, puis multipliez par 5/9 : °C = (°F − 32) × 5/9. Pour 72°F, le calcul donne (72 − 32) × 5/9 = 40 × 5/9 ≈ 22,22°C. D’abord la soustraction, ensuite la multiplication — l’ordre inverse produit un résultat faux.

À quelle température le Celsius et le Fahrenheit sont-ils égaux ?

À exactement −40 degrés. Poser °C = °F dans la formule de conversion donne °C = °C × 9/5 + 32, dont la solution est °C = −40. C’est la seule température où les deux échelles indiquent le même nombre, un repère utile à la fois pour les vrais coups de froid et pour détecter les bugs de direction de conversion.

Comment convertir 350°F en Celsius pour la pâtisserie ?

350°F vaut environ 176,67°C. Les recettes européennes arrondissent généralement à 180°C, et beaucoup de tables de conversion américain-vers-métrique utilisent 175°C. Les deux marchent dans un four domestique — la stabilité de température à cette plage est pire que l’erreur d’arrondi. Passez par notre outil convertisseur de température pour des valeurs exactes quand la précision compte.

Combien font 100°F en Celsius ?

100°F ≈ 37,78°C. Juste au-dessus de la température corporelle normale (37°C / 98,6°F), souvent signalé comme le début d’une fièvre légère. Les recommandations médicales retiennent en général 38°C / 100,4°F comme seuil de fièvre avéré — 100°F reste donc à la limite sans être encore cliniquement significatif.

Pourquoi le zéro absolu est-il −273,15°C et pas simplement −273 ?

Parce que la redéfinition du SI de 2019 a fixé exactement la constante de Boltzmann, ce qui fait de −273,15°C la valeur calculée précise du zéro absolu plutôt qu’une approximation arrondie. Avant 2019, le zéro Celsius était rattaché au point triple de l’eau et le 0,15 provenait d’une mesure. C’est désormais exact par définition.

Quand utiliser le Kelvin plutôt que le Celsius dans le code ?

Dès qu’on multiplie, divise ou élève une température à une puissance — rayonnement du corps noir (T⁴), calculs de gaz parfait, vitesses de réaction. Le Kelvin ne devient jamais négatif, donc la division reste stable. Pour les différences de température, Celsius et Kelvin sont interchangeables (une variation de 5 degrés est la même dans les deux).

Le Rankine est-il encore utilisé en 2026 ?

Oui, mais de façon restreinte. L’ingénierie mécanique, CVC et aérospatiale américaine garde le Rankine pour l’analyse des cycles thermodynamiques quand toutes les autres entrées sont en Fahrenheit. En dehors de ces domaines et hors des États-Unis, il est effectivement mort. Pour un logiciel polyvalent, supporter le Rankine est une assurance peu coûteuse, rarement structurante.

Comment convertir une température dans une requête SQL ?

Inscrivez la formule en ligne ou utilisez une colonne GENERATED ALWAYS AS. Exemple : SELECT celsius * 9.0 / 5.0 + 32.0 AS fahrenheit FROM readings. Les 9.0 et 5.0 (et non 9 et 5) forcent l’arithmétique en virgule flottante dans la plupart des dialectes — la division entière tronque silencieusement. Ajoutez un CHECK (celsius >= -273.15) pour rejeter les valeurs absurdes à l’insertion.

Quel est le moyen le plus simple de convertir Celsius en Fahrenheit de tête ?

Doublez la valeur Celsius et ajoutez 30. 22°C × 2 + 30 = 74°F (réel 71,6°F). Précis à environ 2°F près sur la plage 0–30°C, qui couvre presque toute la météo et les températures intérieures. Dans l’autre sens, soustrayez 30 au Fahrenheit et divisez par deux.

Pourquoi mon convertisseur de température renvoie-t-il 98,599999 pour 37°C ?

Parce que 9/5 = 1,8 n’a pas de représentation exacte en virgule flottante binaire, 37 × 9 / 5 + 32 sort en 98.60000000000001 plutôt qu’en 98.6. C’est le comportement IEEE 754, pas un bug. Utilisez toFixed(2) pour l’affichage, ou passez à une bibliothèque décimale si la précision des chiffres de fin compte dans votre domaine.

Puis-je stocker les températures en entiers pour éviter les problèmes de virgule flottante ?

Oui — stockez des déci-Celsius (la température multipliée par 10). 37,0°C devient 370, 22,5°C devient 225. L’arithmétique entière est exacte, et on ne divise par 10 qu’à la frontière d’affichage. Ce modèle est courant dans les systèmes embarqués et les bases de données de séries temporelles à haut volume où le disque et le CPU comptent.

Comment gérer les nombres sans unité dans une réponse d’API ?

Ne le faites pas. Chaque champ de température doit porter une unité explicite, soit dans le nom du champ (temp_celsius, temp_k), soit dans un champ frère unit. Côté consommateur, si l’API ne fournit pas l’info, documentez l’hypothèse bruyamment dans le code et écrivez un test de contrat qui casse si le défaut de l’API change.

Quel est le point d’ébullition de l’eau dans les quatre échelles ?

100°C = 212°F = 373,15 K = 671,67°R, à pression atmosphérique standard (une atmosphère, 101,325 kPa). La pression joue : à l’altitude de Denver, l’eau bout vers 95°C ; au sommet de l’Everest, plus près de 71°C. Le point d’ébullition dépend de la pression, ce n’est pas une constante universelle.

La température affecte-t-elle les calculs en virgule flottante différemment des autres nombres ?

Non — les valeurs de température se comportent comme n’importe quel autre nombre en virgule flottante. Le piège pratique : les facteurs 5/9 et 9/5 des formules de conversion introduisent une erreur d’arrondi à chaque étape. Pour des valeurs Kelvin entre 200 et 400, la précision est largement suffisante. Pour des valeurs Celsius sub-zéro proches du bord des doubles représentables, la précision reste correcte. Le vrai piège, ce sont les conversions enchaînées qui accumulent de petites erreurs — convertissez une fois, stockez la forme canonique.