MSN Messenger a embarqué un système d'émoticônes qui semblait anodin à l'usage, mais qui reposait sur une architecture technique précise, avec ses propres contraintes de format, de protocole et de compatibilité. Derrière le sourire jaune se cachait une pile technique cohérente, construite par Microsoft entre 1999 et 2013, et qui mérite d'être disséquée.
Les codes texte : syntaxe et interprétation par le client
La base du système repose sur des séquences de caractères ASCII que le client MSN intercepte avant affichage. Ces codes sont envoyés comme du texte brut dans le flux de messages, puis transformés localement en images par l'interface.
La syntaxe suit un schéma simple : un ou deux caractères spéciaux encadrent un identifiant. Le smiley souriant est :), le clin d'oeil ;), la grimace :S. Certains codes acceptent des variantes : :-) et :) déclenchent le même rendu. Le client maintient une table de correspondance interne qui mappe chaque séquence reconnue vers un identifiant d'image.
L'interprétation se fait côté client uniquement. Le serveur MSNP ne traite pas ces séquences - il les transmet comme n'importe quel caractère. Si votre interlocuteur utilisait un client alternatif ou une ancienne version, il voyait les caractères bruts, pas l'image. Ce comportement explique pourquoi les émoticônes personnalisées posaient des problèmes supplémentaires, traités par un mécanisme distinct.
Format .gif animé : contraintes de taille et de palette
Les émoticônes MSN intégrées utilisent le format GIF, retenu pour sa compatibilité avec les animations et sa palette indexée sur 256 couleurs. Microsoft a fixé des contraintes strictes sur les dimensions : les images intégrées mesurent 19x19 pixels, ce qui correspond à la hauteur d'une ligne de texte dans l'interface standard.
Pour les émoticônes personnalisées que les utilisateurs pouvaient créer et partager, les contraintes étaient légèrement différentes :
- Dimensions maximales : 50x50 pixels
- Taille du fichier : limitée à 6 Ko en version 7.x, portée à 7 Ko dans les versions ultérieures
- Format accepté : GIF uniquement, statique ou animé
- Nombre de frames pour les GIF animés : non plafonné explicitement, mais la limite de poids imposait un compromis court
La palette 256 couleurs du GIF n'est pas neutre : elle oblige à un choix de teintes et génère des artefacts de dithering si le graphisme source utilise des dégradés. Les créateurs d'émoticônes tierces devaient anticiper ces contraintes dès la conception, sous peine d'obtenir un rendu altéré après compression.
La transparence GIF (1 bit) était prise en charge, ce qui permettait d'intégrer les images dans n'importe quelle couleur de fond de conversation. La transparence alpha sur 8 bits - propre au PNG - n'était pas supportée.
Le protocole MSNP et la transmission des emoticones personnalisées
Le protocole MSNP (MSN Messenger Protocol) gère les échanges entre clients et serveurs. La transmission d'émoticônes personnalisées mobilise une partie spécifique de ce protocole : le canal de transfert de données de session, distinct du canal texte.
Lorsqu'un utilisateur insère une émoticônes personnalisée dans un message, le client envoie d'abord le message texte avec un code de substitution entre accolades - par exemple {ange}. Il joint à cette transmission une notification indiquant que ce code correspond à un objet graphique à récupérer. Le client destinataire émet alors une requête de transfert vers le client émetteur, via une connexion directe de type peer-to-peer si possible, ou relayée par les serveurs Microsoft sinon.
Ce transfert utilise le sous-protocole MSNSLP (MSN Session Layer Protocol), qui encapsule lui-même des échanges SIP simplifiés. La séquence complète comprend :
- Une invitation MSNSLP avec le hash MD5 du fichier image
- Une réponse d'acceptation ou de refus du destinataire
- Le transfert binaire du fichier GIF par blocs
- Une confirmation de réception et de fermeture de session
Le hash MD5 sert de cache côté destinataire : si l'image a déjà été reçue lors d'une session précédente, le client ne relance pas le transfert et utilise le fichier local. Ce mécanisme réduit la charge réseau sur des connexions ADSL dont le débit montant était souvent inférieur à 128 Ko/s.
Emoticones intégrées versus emoticones tierces : différences techniques
Les émoticônes intégrées sont embarquées dans les fichiers du client MSN, dans un répertoire dédié du dossier d'installation. Elles ne transitent jamais par le réseau lors d'une conversation : seul le code texte est transmis, et le rendu est garanti identique des deux côtés puisque les deux clients disposent du même jeu d'images.
Les émoticônes tierces, elles, introduisent une asymétrie. L'émetteur voit son image personnalisée ; le destinataire voit d'abord le code brut entre accolades, puis l'image après réception du transfert. Si le destinataire refuse le transfert (ou si son client ne le supporte pas), il reste avec le code texte.
Les différences techniques entre les deux catégories sont nettes :
| Critère | Emoticones intégrées | Emoticones tierces |
|---|---|---|
| Stockage | Local, dans le répertoire client | Local, dans le profil utilisateur |
| Transmission réseau | Aucune | Transfert P2P via MSNSLP |
| Dépendance au destinataire | Aucune | Acceptation et client compatible requis |
| Taille maximale | 19x19 px (natif) | 50x50 px |
Cette architecture à deux niveaux reflète une contrainte de déploiement : Microsoft ne pouvait pas modifier en temps réel le jeu d'images intégré sans pousser une mise à jour du client. Les émoticônes tierces contournaient cette rigidité en déportant la gestion du contenu vers les utilisateurs eux-mêmes.
Pourquoi ce système n'a pas survécu à la migration vers Skype?
Microsoft a racheté Skype en 2011 pour 8,5 milliards de dollars et a commencé à migrer les utilisateurs MSN vers Skype dès 2012. La fermeture définitive de MSN Messenger a eu lieu en octobre 2014. Le système d'émoticônes MSN n'a pas été porté tel quel, et les raisons sont techniques autant que stratégiques.
Skype repose sur un protocole propriétaire fondamentalement différent de MSNP. Reconstruire la couche MSNSLP de transfert d'émoticônes sur ce socle aurait demandé un travail d'intégration conséquent, pour un gain marginal. Skype avait déjà son propre jeu d'émoticônes, avec une résolution supérieure et un format étendu.
La tendance de fond jouait aussi contre ce système. Les émoticônes personnalisées en GIF 50x50 px étaient pensées pour des réseaux à faible débit. En 2012, la généralisation du haut débit et des smartphones déplaçait les usages vers des stickers haute résolution, des GIF animés lourds, et des images embarquées directement dans les messages. Le mécanisme de transfert P2P de MSN, ingénieux pour 2004, semblait archaïque face à un simple partage d'image inline.
Le cache MD5 local, les limites à 6-7 Ko, la palette 256 couleurs : chaque contrainte technique qui avait rendu ce système robuste sur les connexions bas débit devenait une limite visible sur des écrans haute densité et des connexions fibre. Ce n'est pas le système qui a échoué - c'est l'environnement technique qui l'a rendu obsolète avant même que Microsoft choisisse de l'abandonner.
