Algorithme de Luhn pour la validation IMEI : comment fonctionne le chiffre de contrôle

Vous mettez en place un système automatisé pour valider des numéros IMEI issus d’une plateforme de gestion de parc. 10 000 entrées. Certaines sont manifestement incorrectes — une faute de frappe, un placeholder 000000000000000, une valeur collée avec des espaces. Comment éliminer le bruit sans appeler une API pour chaque entrée ? L’algorithme de Luhn. 10 lignes de code, exécution en quelques millisecondes, et vous avez éliminé 95 % des IMEI invalides avant la moindre requête réseau.

Ce n’est pas un exercice théorique. Toute équipe gérant des flottes d’appareils — plateformes MDM, opérateurs télécom, systèmes d’assurance, marchés de l’occasion — se retrouve face à ce problème à grande échelle. Comprendre le fonctionnement de l’algorithme de Luhn, et ses limites, est une connaissance fondamentale pour quiconque construit sur des données IMEI.

Qu’est-ce que l’algorithme de Luhn ?

L’algorithme de Luhn — formellement connu sous le nom de formule de Luhn ou algorithme modulo 10 — a été créé par Hans Peter Luhn, ingénieur chez IBM. Il l’a breveté en 1954, initialement comme mécanisme simple de protection contre les erreurs accidentelles de saisie dans les numéros d’identification.

L’algorithme n’a jamais été conçu comme une mesure de sécurité cryptographique. Son objectif était précis et pratique : détecter les erreurs de transcription humaines les plus courantes — un chiffre incorrect, deux chiffres adjacents inversés — avant qu’un numéro ne soit traité plus loin dans la chaîne.

Cette simplicité pratique l’a rendu omniprésent. Aujourd’hui, l’algorithme de Luhn est intégré dans :

• Les numéros de carte bancaire (Visa, Mastercard, American Express) — un numéro valide Luhn est un prérequis avant toute tentative d’autorisation bancaire
• Les numéros IMEI — exigé par la Recommandation ITU-T E.118 et appliqué par le GSMA pour chaque appareil mobile vendu dans le monde
• Les numéros d’assurance sociale canadiens (NAS)
• Certains numéros NPI (National Provider Identifier) dans le système de santé américain
• Les numéros ICCID des cartes SIM

Pour les IMEI en particulier, la spécification Device Check du GSMA exige que tout IMEI à 15 chiffres comporte un chiffre de contrôle Luhn valide comme condition d’intégrité de base. Tout appareil qui échoue à cette vérification est structurellement invalide.

L’algorithme est computationnellement trivial : O(n) où n est le nombre de chiffres. Sur du matériel moderne, valider 10 000 IMEI prend moins d’une milliseconde. Cela en fait un pré-filtre idéal avant tout appel à une API externe.

L’algorithme de Luhn étape par étape

Parcourons l’algorithme avec l’IMEI réel 356938035643809.

Cet IMEI se décompose ainsi :

• Charge utile 14 chiffres : 35693803564380
• Chiffre de contrôle : 9

L’objectif est de vérifier que le chiffre de contrôle 9 est correct.

IMEI :     3  5  6  9  3  8  0  3  5  6  4  3  8  0  9
Position: 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1

Étape 1 — Doubler un chiffre sur deux en partant de la droite.

À partir de la position 2 (avant-dernier chiffre), doubler chaque chiffre en position paire (depuis la droite). Les positions impaires restent inchangées.

Position :  15 14 13 12 11 10  9  8  7  6  5  4  3  2  1
Chiffre :    3  5  6  9  3  8  0  3  5  6  4  3  8  0  9
Doubler ? :  -  x  -  x  -  x  -  x  -  x  -  x  -  x  -
Résultat :   3 10  6 18  3 16  0  6  5 12  4  6  8  0  9

Étape 2 — Soustraire 9 de toute valeur doublée supérieure à 9.

C’est équivalent à additionner les deux chiffres du résultat (par exemple, 10 donne 1+0=1, 18 donne 1+8=9).

10 → 1
18 → 9
16 → 7
6  → 6
12 → 3
6  → 6
0  → 0

Séquence mise à jour : 3, 1, 6, 9, 3, 7, 0, 6, 5, 3, 4, 6, 8, 0, 9

Étape 3 — Additionner tous les 15 chiffres.

3+1+6+9+3+7+0+6+5+3+4+6+8+0+9 = 70

Étape 4 — Vérifier la divisibilité par 10.

Si la somme totale est divisible par 10, l’IMEI est valide.

70 mod 10 = 0 → Valide ✓

Calculer le chiffre de contrôle (mode génération) :

Si vous disposez d’une charge utile de 14 chiffres et devez calculer le chiffre de contrôle :

Somme des 14 chiffres (après doublement) = 61
Chiffre de contrôle = (10 - (61 mod 10)) mod 10 = (10 - 1) mod 10 = 9

Pourquoi l’algorithme détecte la plupart des erreurs

Une erreur sur un seul chiffre modifie la somme de Luhn d’une valeur non nulle qui n’est presque jamais un multiple de 10. Plus précisément :

• Toute erreur sur un seul chiffre est toujours détectée (taux de détection de 100 % pour les transpositions à un chiffre)
• Les inversions de chiffres adjacents (par exemple 35 devenant 53) sont détectées dans la plupart des cas — la seule exception concerne l’inversion de deux chiffres identiques, qui ne change rien
• La corruption aléatoire — taux de détection d’environ 90 % pour les erreurs multi-chiffres aléatoires

Ce que Luhn ne peut pas détecter : toute manipulation produisant intentionnellement un chiffre de contrôle valide, ou toute corruption fortuite qui préserve la divisibilité par 10.

Structure d’un IMEI — ce que chaque partie signifie

Un IMEI est un numéro à 15 chiffres défini par l’ITU-T E.212 et géré par le GSMA. Il est structuré en trois champs contigus :

TAC — Type Allocation Code (chiffres 1 à 8)

Le TAC identifie le type d’appareil : fabricant et modèle. Il est alloué par le GSMA lors de la certification de l’appareil. Les deux premiers chiffres du TAC identifiaient historiquement l’organisme de déclaration (par exemple, 35 était alloué au British Approvals Board for Telecommunications), bien que l’attribution des TAC ait évolué depuis.

Exemple : 35693803 appartient à un modèle Samsung. Les fabricants reçoivent des blocs de TAC et doivent enregistrer chaque modèle avant la commercialisation. Un lookup TAC peut indiquer le fabricant, le nom du modèle, et parfois les bandes de fréquences supportées.

Numéro de série — SNR (chiffres 9 à 14)

Six chiffres identifiant de manière unique l’unité spécifique au sein d’un TAC donné. Les fabricants les attribuent séquentiellement dans la plupart des lignes de production, bien que certains utilisent des schémas aléatoires pour empêcher l’énumération des unités. Il y a jusqu’à 1 000 000 de numéros de série possibles par TAC.

Chiffre de contrôle (chiffre 15)

Le chiffre final, calculé via l’algorithme de Luhn sur les 14 chiffres précédents. Son seul objectif est la détection d’erreurs. Il ne contient aucune information sur l’appareil.

Motifs IMEI invalides courants

Au-delà de l’échec au contrôle Luhn, certains IMEI structurellement valides sont sémantiquement invalides par convention :

Motif	Raison
000000000000000	Placeholder — utilisé par les appareils réinitialisés en usine, émulateurs, et machines virtuelles
111111111111111	IMEI de test — passe Luhn mais n’est jamais un vrai appareil
123456789012345	Valeur de test séquentielle
490154203237518	IMEI de test couramment utilisé en développement
Toute valeur de moins de 15 chiffres	Structurellement malformé

Un validateur robuste doit signaler tous ces motifs en plus du contrôle Luhn.

Implémenter le contrôle Luhn — exemples de code

Python

def luhn_check(imei: str) -> bool:
    digits = [int(d) for d in imei if d.isdigit()]
    if len(digits) != 15:
        return False
    check_sum = 0
    for i, d in enumerate(reversed(digits)):
        if i % 2 == 1:
            d *= 2
            if d > 9:
                d -= 9
        check_sum += d
    return check_sum % 10 == 0

Utilisation :

>>> luhn_check("356938035643809")
True
>>> luhn_check("356938035643800")
False
>>> luhn_check("000000000000000")
False

La fonction supprime d’abord les caractères non numériques, ce qui gère correctement les entrées comme "35 693803 564380 9" (avec espaces). Elle renvoie False pour toute entrée qui ne fait pas exactement 15 chiffres après suppression, puis applique le contrôle Luhn.

JavaScript

function luhnCheck(imei) {
  const digits = imei.replace(/\D/g, '');
  if (digits.length !== 15) return false;
  let sum = 0;
  for (let i = 0; i < 15; i++) {
    let d = parseInt(digits[14 - i]);
    if (i % 2 === 1) { d *= 2; if (d > 9) d -= 9; }
    sum += d;
  }
  return sum % 10 === 0;
}

Pipeline de validation en masse (Python)

def validate_imei_batch(imei_list: list[str]) -> dict:
    KNOWN_INVALID = {"000000000000000", "111111111111111", "123456789012345"}
    results = {"valid": [], "invalid_format": [], "invalid_luhn": [], "known_bad": []}
    for raw in imei_list:
        imei = raw.replace(" ", "").replace("-", "")
        if not imei.isdigit() or len(imei) != 15:
            results["invalid_format"].append(raw)
        elif imei in KNOWN_INVALID:
            results["known_bad"].append(raw)
        elif not luhn_check(imei):
            results["invalid_luhn"].append(raw)
        else:
            results["valid"].append(imei)
    return results

Pour la validation visuelle d’IMEI individuels sur le terrain, utilisez le calculateur IMEI/Luhn.

Validation Luhn vs vérification IMEI complète

C’est la distinction la plus importante à intérioriser : la validation Luhn est un contrôle de format, pas un contrôle d’appareil.

Un IMEI valide selon Luhn vous indique que le numéro est bien formé structurellement. Il ne vous dit rien sur l’existence d’un vrai appareil fabriqué avec cet IMEI, si l’appareil figure sur une liste noire réseau, ou si le TAC correspond à un fabricant légitime.

Type de contrôle	Détecte	Ne détecte PAS
Algorithme de Luhn	Erreurs de transcription, format invalide	Appareil réel ou fictif, statut blacklist
Lookup TAC	Fausse revendication de modèle, TAC inexistant	Blacklist, activation lock
Vérification blacklist IMEI	Appareils signalés volés/perdus	Faux IMEI non signalés
Requête EIR réseau	IMEI bloqués chez cet opérateur	IMEI bloqués chez d’autres opérateurs

Considérons la surface d’attaque : un acteur malveillant suffisamment motivé peut générer un nombre illimité d’IMEI valides selon Luhn en choisissant un TAC valide, en ajoutant un numéro de série aléatoire à 6 chiffres, et en calculant le chiffre de contrôle correct. Le numéro résultant passera le contrôle Luhn à chaque fois. C’est pourquoi la vérification blacklist existe.

La vérification blacklist IMEI va au-delà de Luhn pour vérifier le statut blacklist réseau dans des bases de données en temps réel.

Quand Luhn seul suffit

La validation Luhn uniquement est appropriée lorsque :

• Vous assainissez la saisie utilisateur en temps réel (validation de formulaire, retour clavier mobile)
• Vous effectuez un filtrage initial en masse sur une grande importation avant de consommer du quota API
• Le système en aval possède sa propre couche de vérification et vous avez seulement besoin d’empêcher des données manifestement malformées d’y entrer

Quand le pipeline complet est nécessaire

La vérification complète TAC + blacklist est requise lorsque :

• Vous achetez ou acceptez un appareil pour la revente
• Vous traitez une demande d’indemnisation impliquant un appareil
• Vous activez un appareil sur un réseau
• Vous intégrez des appareils dans une plateforme MDM/EMM et devez vérifier qu’ils ne sont pas signalés volés

L’architecture correcte est toujours : Luhn en premier (gratuit, synchrone, latence nulle), puis lookup TAC, puis vérification blacklist — dans cet ordre. Vous éliminez les entrées manifestement invalides à coût zéro avant de dépenser des appels API sur le reste.

Conclusion

L’algorithme de Luhn est la première et la plus rapide des couches de validation pour tout système traitant des numéros IMEI. Ce n’est pas un mécanisme de sécurité — c’est un mécanisme de qualité des données. Une seule implémentation de la fonction de 10 lignes ci-dessus, déployée au point de saisie, élimine la majorité des entrées invalides avant toute requête réseau.

L’insight structurel à retenir : Luhn valide le format d’un IMEI. Le lookup TAC valide l’origine. La vérification blacklist valide le statut. Les trois couches servent des objectifs différents et aucune ne peut remplacer les autres. Dans un système de production qui traite des IMEI à grande échelle, les trois appartiennent au pipeline.

---

Quelle couche de validation IMEI a identifié le plus de problèmes dans votre système — le contrôle de format Luhn, le lookup TAC ou la vérification blacklist ? Partagez votre expérience en commentaires.