Accueil › Glossaire › Stemming

Stemming

Le stemming est une technique de traitement du langage naturel (NLP) qui réduit un mot à sa racine (appelée « stem ») en supprimant ses suffixes et préfixes selon des règles heuristiques, sans nécessiter de dictionnaire ni d’analyse morphologique complète.

Concrètement, le stemming transforme « connexion », « connexions », « connectif », « connectés » et « connectant » en une forme commune comme « connect ». Le résultat n’est pas forcément un mot valide du dictionnaire, et c’est précisément ce qui le différencie de la lemmatisation. L’objectif n’est pas la correction linguistique mais la cohérence : regrouper les variantes flexionnelles d’un même terme sous une forme unique pour faciliter l’indexation, la recherche et l’analyse de texte.

Pourquoi le stemming existe

Imaginez un moteur de recherche. Un utilisateur tape « chats ». Sans stemming, les documents contenant « chat », « chatons » ou « chatterie » ne remontent pas. Le vocabulaire explose, la pertinence chute. Le stemming résout ce problème en normalisant toutes ces formes vers une racine commune, réduisant drastiquement la taille du vocabulaire indexé. Sur un corpus de 100 millions de mots, vous pouvez passer de 500 000 formes fléchies uniques à environ 200 000 stems, soit une réduction de 60 % de la dimensionnalité.

Cette réduction a trois conséquences directes. Premièrement, les modèles statistiques de NLP gagnent en précision car la dispersion du vocabulaire diminue. Deuxièmement, les index de recherche deviennent plus compacts et plus rapides. Troisièmement, le rappel (recall) augmente puisque des variantes morphologiques sont désormais regroupées.

Avant 2003, une recherche Google pour « fish » ne retournait pas les pages contenant « fishes » ou « fishing ». L’intégration du stemming a fondamentalement changé la pertinence des résultats de recherche.

Comment fonctionne le stemming

Le stemming opère par correspondance de chaînes de caractères et application de règles, sans consultation de dictionnaire ni analyse syntaxique. Voici le processus simplifié :

Le mot est d’abord analysé pour identifier ses suffixes. L’algorithme applique ensuite des règles de suppression conditionnelles : il ne retire pas aveuglément les terminaisons, mais vérifie d’abord la structure du mot restant. Par exemple, dans l’algorithme de Porter, la règle « -ED » ne supprime pas simplement « ed » de manière uniforme : dans « cared », seul le « d » est retiré, tandis que dans « jumped », « ed » est retiré en entier. Enfin, des règles de nettoyage corrigent les doubles consonnes (« stemmed » devient « stem », pas « stemm »).

Toute la logique repose sur une mesure appelée m (measure), qui compte le nombre de séquences voyelle-consonne dans un mot. Les règles utilisent des conditions comme « supprimer le suffixe X si m > 1 », ce qui garantit que le stem résultant conserve une substance minimale.

Exemple concret pas à pas

Prenons le mot anglais « generalizations » avec l’algorithme Snowball (Porter2) :

Étape 1 : Suppression du pluriel. « generalizations » → « generalization » (suppression du « s »).
Étape 2 : Suppression des suffixes dérivationnels. « generalization » → « generalize » (suppression de « -ation »).
Étape 3 : Nettoyage final. « generalize » → « general » (suppression de « -ize »).

Le stem « general » est ici un mot valide, mais ce n’est pas toujours le cas. « happily » devient « happili » avec Porter, et « was » devient « wa ». Ce comportement est volontaire : le stemming vise la cohérence des regroupements, pas la validité linguistique.

Les principaux algorithmes de stemming

Porter Stemmer (1980)

Créé par Martin Porter et publié dans le journal Program en juillet 1980, c’est l’algorithme fondateur. Il fonctionne en 5 phases séquentielles appliquant environ 60 règles de suppression de suffixes. Chaque phase traite un type de suffixe spécifique : la phase 1 gère les pluriels et les participes passés, les phases suivantes traitent les suffixes dérivationnels de manière progressive.

Ses forces : simplicité, rapidité, faible empreinte mémoire. Ses limites : il ne gère que l’anglais, et produit parfois des stems linguistiquement incorrects (« was » → « wa », « mice » → « mice » sans changement). Martin Porter lui-même considère cet algorithme comme « gelé » (frozen) et recommande d’utiliser Snowball à la place.

Snowball Stemmer / Porter2

Également créé par Martin Porter, Snowball est à la fois un langage de programmation dédié à la création d’algorithmes de stemming et une collection d’algorithmes implémentés dans ce langage. Le stemmer anglais de Snowball, appelé Porter2, corrige les défauts du Porter original tout en maintenant sa vitesse.

L’atout majeur de Snowball est son support multilingue. Le compilateur Snowball traduit les algorithmes en Ada, C, C#, Dart, Go, Java, JavaScript, Object Pascal, PHP, Python et Rust. La communauté contribue régulièrement de nouveaux stemmers : le polonais a été ajouté en octobre 2025, l’espéranto en mars 2025, et la version 3.0.0 de Snowball est sortie en mai 2025.

Les langues supportées incluent l’anglais, le français, l’allemand, l’espagnol, le portugais, l’italien, le néerlandais, le suédois, le norvégien, le danois, le finnois, le hongrois, le roumain, le russe, le turc, l’arabe, et bien d’autres. Pour la plupart des applications en anglais, Snowball (Porter2) est le stemmer recommandé.

Lancaster Stemmer (1990)

Développé par C.D. Paice à l’Université de Lancaster, cet algorithme utilise une approche itérative qui le rend beaucoup plus agressif que Porter ou Snowball. Il applique ses règles en boucle jusqu’à ce qu’aucune ne s’applique plus, ce qui produit des stems très courts. Par exemple, « mice » devient « mic ».

Cette agressivité provoque davantage d’erreurs de sur-stemming (over-stemming), où des mots sémantiquement différents se retrouvent avec le même stem. Il ne supporte que l’anglais et est moins efficace que Porter ou Snowball dans la plupart des cas. Son usage reste marginal.

Lovins Stemmer (1968)

Le tout premier stemmer publié, créé par Julie Beth Lovins. Il utilise une liste de 294 suffixes et les supprime en une seule passe, suivie d’une étape de « recoding » pour corriger les stems malformés (« hopp » → « hop »). Il est historiquement important mais rarement utilisé aujourd’hui. Dans Elasticsearch, les valeurs « Kp » et « Lovins » du filtre Snowball sont d’ailleurs marquées comme dépréciées depuis la version 8.16.0.

Le stemming en français

Le français pose des défis spécifiques au stemming à cause de sa morphologie riche : conjugaisons complexes (six personnes, multiples temps et modes), élisions (l’, d’, n’), accents diacritiques, et liaisons. L’algorithme Snowball intègre un stemmer français dédié avec des règles adaptées.

Le stemmer français de Snowball utilise une région spéciale appelée RV, définie différemment de l’anglais : si le mot commence par deux voyelles, RV est la région après la troisième lettre. Sinon, c’est la région après la première voyelle qui ne se trouve pas au début du mot. Les exceptions incluent les préfixes « par », « col » et « tap ».

Voici un exemple concret avec le Snowball FrenchStemmer appliqué à la phrase « Bouygues a eu une coupure de réseau à Marseille » :

from nltk.stem.snowball import SnowballStemmer
stemmer = SnowballStemmer(language='french')

mots = ["Bouygues", "a", "eu", "une", "coupure", "de", "réseau", "à", "Marseille"]
stems = [stemmer.stem(mot) for mot in mots]
print(stems)
# ['bouygu', 'a', 'eu', 'une', 'coupur', 'de', 'réseau', 'à', 'marseil']

On constate que « Bouygues » devient « bouygu », « coupure » devient « coupur » et « Marseille » devient « marseil ». Ces stems ne sont pas des mots français valides, mais ils permettent de regrouper les variantes (« coupure », « coupures », « coupé » partagent la racine « coup- »).

Pour le français en production, Elasticsearch propose plusieurs variantes via son filtre stemmer : french (Snowball standard), light_french (moins agressif) et minimal_french (très conservateur). Le choix dépend de votre tolérance au sur-stemming.

PUT /articles_fr
{
  "settings": {
    "analysis": {
      "filter": {
        "french_stemmer": {
          "type": "stemmer",
          "language": "light_french"
        },
        "french_stop": {
          "type": "stop",
          "stopwords": "_french_"
        },
        "french_elision": {
          "type": "elision",
          "articles": ["l", "m", "t", "qu", "n", "s", "j", "d", "c"]
        }
      },
      "analyzer": {
        "french_analyzer": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": ["french_elision", "lowercase", "french_stop", "french_stemmer"]
        }
      }
    }
  }
}

Implémentation en Python avec NLTK

NLTK (Natural Language Toolkit) est la librairie de référence pour le stemming en Python. Elle fournit les implémentations de Porter, Snowball et Lancaster.

Porter Stemmer

from nltk.stem import PorterStemmer

stemmer = PorterStemmer()
mots = ["caresses", "flies", "dies", "denied", "meeting", "sensational"]
stems = [stemmer.stem(mot) for mot in mots]
print(stems)
# ['caress', 'fli', 'die', 'deni', 'meet', 'sensat']

Notez que « flies » devient « fli » et « sensational » devient « sensat ». Ces résultats sont linguistiquement incorrects mais cohérents : toutes les formes de « fly » convergent vers « fli ».

Snowball Stemmer

from nltk.stem.snowball import SnowballStemmer

# Voir les langues disponibles
print(SnowballStemmer.languages)
# ('arabic', 'danish', 'dutch', 'english', 'finnish', 'french',
#  'german', 'hungarian', 'italian', 'norwegian', 'porter',
#  'portuguese', 'romanian', 'russian', 'spanish', 'swedish')

stemmer = SnowballStemmer(language='english')
print(stemmer.stem("generously"))  # 'generous'

# Comparer avec Porter
stemmer_porter = SnowballStemmer("porter")
print(stemmer_porter.stem("generously"))  # 'gener'

La différence est nette : Snowball produit « generous » (un mot valide) là où Porter produit « gener ». C’est pourquoi Snowball est systématiquement préféré pour les nouvelles implémentations.

Ignorer les stopwords

from nltk.stem.snowball import SnowballStemmer

stemmer_normal = SnowballStemmer("english")
stemmer_stop = SnowballStemmer("english", ignore_stopwords=True)

print(stemmer_normal.stem("having"))  # 'have'
print(stemmer_stop.stem("having"))    # 'having' (inchangé)

L’option ignore_stopwords=True évite de stemmer les stopwords, ce qui peut améliorer la qualité de certains pipelines de traitement en préservant les mots fonctionnels dans leur forme originale.

Stemming vs lemmatisation : quelle différence

La confusion entre stemming et lemmatisation est fréquente. Voici la distinction fondamentale : le stemming coupe les fins de mots par des règles heuristiques, la lemmatisation utilise un dictionnaire et l’analyse morphologique pour retrouver la forme de base (le lemme).

En pratique, spaCy ne propose d’ailleurs aucune fonction de stemming : la librairie s’appuie exclusivement sur la lemmatisation, considérée comme plus fiable pour les pipelines NLP modernes.

Les erreurs classiques du stemming

Over-stemming (sur-stemming)

Le sur-stemming se produit quand des mots sémantiquement différents sont réduits au même stem. L’exemple classique : « universal », « university » et « universe » deviennent tous « univers ». Ces trois mots n’ont pas le même sens, mais le stemmer les fusionne. Dans un moteur de recherche, une requête sur « university » remonterait alors des résultats sur « l’univers », ce qui dégrade la précision.

Under-stemming (sous-stemming)

Le sous-stemming est le problème inverse : des mots qui devraient partager le même stem ne le font pas. Les formes irrégulières sont les principales victimes. « run », « ran » et « running » ne convergent pas toujours vers le même stem selon l’algorithme. Cela fragmente l’index et réduit le rappel.

Des études comparatives montrent que les taux d’erreur du stemmer Porter en anglais oscillent entre 15 et 25 % selon le corpus. Pour les langues à morphologie riche comme le finnois, ce taux peut dépasser 30 %.

Erreurs à éviter en production

Ne jamais afficher les stems à l’utilisateur. Si votre interface montre « comput » au lieu de « compute », vous perdez la confiance de l’utilisateur. Gardez les stems exclusivement dans l’index interne. Ne jamais appliquer le stemming avant la reconnaissance d’entités nommées (NER), car vous détruisez les signaux nécessaires à l’identification des entités. Ne jamais supposer que le stemming préserve le sens dans tous les contextes : « marketing » stemmé en « market » mélange des documents sur les stratégies marketing avec ceux sur les marchés boursiers.

Cas d’usage en production

Moteurs de recherche

C’est le cas d’usage historique et le plus répandu. Google, Bing, Elasticsearch, Apache Solr utilisent tous des variantes du stemming pour l’indexation. Elasticsearch intègre nativement les filtres Porter, Snowball et KStem via son API d’analyse. Le tokenizer standard combiné au filtre Snowball est la configuration par défaut pour de nombreuses langues.

Dans un système de recherche booléenne, le stemming ne fait jamais baisser le rappel (car il crée des correspondances plus larges) mais peut légèrement faire baisser la précision. C’est un compromis acceptable quand on traite des milliards de documents.

Text mining et classification

Le stemming réduit la dimensionnalité des features dans les modèles de classification de texte. Combiné avec TF-IDF ou un bag-of-words, il permet de regrouper les variantes morphologiques et d’améliorer les performances des modèles classiques (Naive Bayes, SVM, régression logistique).

Analyse de sentiment simplifiée

Pour une analyse de sentiment basique où la vitesse est prioritaire, le stemming suffit à normaliser le vocabulaire. Pour des analyses plus fines nécessitant la compréhension contextuelle (« not good » vs « good »), la lemmatisation est préférable.

Pipelines hybrides modernes

Dans les architectures de recherche modernes, le stemming s’intègre dans des systèmes hybrides. Vous pouvez lemmatiser les textes pour le modèle d’embedding vectoriel tout en conservant un index stemmé comme solution de repli (fallback) quand la recherche vectorielle échoue. Cette approche combinée est de plus en plus courante dans les systèmes de production.

Stemming et LLM : le stemming est-il encore utile

Avec les grands modèles de langage qui utilisent leurs propres tokenizers basés sur le BPE (Byte Pair Encoding) ou SentencePiece, on peut légitimement se demander si le stemming a encore sa place.

La réponse est oui, mais son rôle a évolué. Les LLM gèrent la normalisation morphologique en interne grâce à leurs embeddings contextuels. Cependant, le stemming reste pertinent pour les index de recherche classiques (Elasticsearch, Solr), les systèmes de RAG qui combinent recherche lexicale et recherche vectorielle, la déduplication de contenu, le caching de requêtes, et les systèmes à faibles ressources computationnelles.

Le stemming ne disparaîtra pas : il s’intègre dans des architectures plus larges. Les systèmes de recherche hybride combinent stemming pour le rappel lexical, embeddings pour la pertinence sémantique, et LLM pour le reranking. Chaque couche apporte une valeur spécifique.