Les types de données algébriques : précision et expressivité

Les types de données algébriques (ADT, pour algebraic data types) constituent le socle de la modélisation dans les langages fonctionnels typés, et leur influence s’étend désormais bien au-delà.

Un ADT se construit par composition de deux opérations fondamentales :

• Le produit (conjonction de champs, « A et B »)
• La somme (disjonction de variantes, « A ou B »)

Cette algèbre simple engendre une expressivité remarquable. Là où les langages orientés objet proposent des classes avec héritage et des interfaces, les ADT offrent une approche plus directe et plus rigoureuse pour décrire la forme exacte des données qu’un programme manipule.

Types produits et types sommes

Les types produits (records, structs, tuples) capturent les entités composées de plusieurs attributs simultanés. Un User possède un name et un email et un createdAt. Rien de révolutionnaire ici ; tous les langages proposent cette construction.

La véritable puissance des ADT réside dans les types sommes : les unions discriminées, les variants, les enums avec données associées.

PaymentStatus = Pending | Completed { transactionId } | Failed { reason }

Chaque variante porte exactement les données pertinentes à son cas. Cette modélisation ferme l’espace des possibilités : il n’existe pas de quatrième état, pas de combinaison hybride.

Pattern matching et exhaustivité

Le pattern matching exploite pleinement cette structure.

Quand on déconstruit un ADT, le compilateur exige l’exhaustivité : chaque variante doit être traitée. Oublier un cas génère une erreur de compilation, pas un bug en production.

Cette garantie statique transforme les refactorings risqués en opérations mécaniques : ajouter une variante au type somme, puis laisser le compilateur guider vers tous les endroits du code qui doivent être adaptés. Ajoutez un statut Refunded à votre type de paiement : chaque switch qui l’oublie devient une erreur de compilation, corrigée en quelques minutes, plutôt qu’un bug découvert en production des semaines plus tard.

Le type devient une source de vérité qui propage automatiquement les changements à travers la codebase. Les erreurs de logique deviennent des erreurs de type. Cette confiance dans le refactoring se traduit directement en vélocité : l’équipe peut faire évoluer le modèle métier sans craindre de casser silencieusement des fonctionnalités existantes.

Encoder les invariants métier

Les ADT permettent d’encoder les invariants métier directement dans la structure des données.

Plutôt qu’un Order avec des champs optionnels dont la validité dépend d’un champ status, on modélise une machine à état explicite :

DraftOrder | ConfirmedOrder | ShippedOrder

chacun avec sa forme propre.

L’état invalide « commande expédiée sans date d’expédition » devient inexprimable : non pas interdit par une validation runtime, mais structurellement impossible. C’est l’essence de Make Illegal States Unrepresentable : les ADT fournissent le vocabulaire pour que le système de types capture les règles métier, pas seulement les types primitifs.

Adoption croissante

TypeScript a démocratisé les ADT dans l’écosystème JavaScript via les unions discriminées et le narrowing automatique. Rust les a rendus idiomatiques avec ses enum porteurs de données et son match exhaustif. Même Java, longtemps limité aux enums simples, a introduit les sealed classes et le pattern matching.

Cette convergence n’est pas fortuite : les ADT répondent à un besoin universel de modélisation précise. Ils réduisent l’écart entre la pensée du développeur (« cette valeur est soit ceci, soit cela ») et le code qui l’exprime.

En rendant le modèle mental explicite et vérifiable, ils éliminent toute une classe d’erreurs où le code et l’intention divergent silencieusement.