Un emoji a gâché toute mon après-midi.
Je traitais 10 000 enregistrements d’avis clients via un pipeline d’analyse de sentiment le mois dernier. Travail propre, workflow simple : scraper les données, normaliser le texte, les passer à TextBlob, extraire les scores de sentiment. Le script de nettoyage fonctionnait impeccablement sur mon dataset de test de 500 lignes. Donc je l’ai envoyé en production.
Après 48 minutes, tout s’arrête net. Aucun message d’erreur. Aucune exception. Aucun avertissement. Juste bloqué, suspendu indéfiniment à la ligne 6 842.
Le cauchemar de debugging que personne ne vous prépare à affronter
Mon premier réflexe ? Une fuite mémoire. Dix mille lignes ne devraient pas étouffer une machine moderne, mais peut-être que quelque chose s’accumulait. J’ai relancé le processus avec le suivi mémoire activé. Exactement le même comportement—bloqué à la ligne 6 842. À chaque fois.
J’ai ouvert le CSV et j’ai examiné manuellement la ligne 6 842. Nom du client : OK. Texte de l’avis : « Ce produit est 💩 ne l’achetez pas. » Note : 5 étoiles (contradictoire, bien sûr, mais pas syntaxiquement cassé). Rien qui m’a sauté aux yeux.
Et puis je l’ai vu.
L’emoji.
C’est là que ma propre négligence rentre en jeu. Ma logique d’encodage—la chose qui aurait dû être blindée—était définie sur encoding='latin-1' parce qu’une version antérieure du dataset contenait des caractères espagnols (ñ, á, é, etc.) qui cassaient en UTF-8. Du coup je l’avais verrouillée.
Latin-1 gère bien les caractères européens. Mais les emojis ? Ce sont des caractères UTF-8 multi-octets. Quand le lecteur CSV de Python a rencontré cet emoji caca, il n’a pas pu le décoder en latin-1. Et au lieu de lever une exception—au lieu de me donner un quelconque retour—il s’est juste figé là, silencieusement étouffé.
Mon dataset de 500 lignes n’avait zéro emoji. Les données de production contenaient 147 emojis sur 10 000 lignes. Tester avec des données réelles aurait détecté ça immédiatement.
C’est la partie vraiment exaspérante. Si j’avais vraiment testé avec des données réalistes au lieu d’un échantillon aseptisé, j’aurais attrapé le problème bien avant le déploiement. Mais c’est pas ce qu’on fait, hein ? On teste avec des datasets jouets et on croise les doigts.
Pourquoi les défaillances silencieuses sont bien pires que les crashes
Un crash aurait été une bénédiction. Un crash te donne une stack trace, un numéro de ligne, un indice. Là, c’était un blocage silencieux—le pire type de bug qu’on puisse avoir. Python a simplement abandonné sans me dire pourquoi. Le module csv ne lève pas d’erreur d’encodage dans ce scénario ; il se bloque juste indéfiniment en essayant de décoder quelque chose qu’il ne peut pas gérer.
La correction, une fois que j’ai compris, était honteusement simple :
import pandas as pd
df = pd.read_csv(
'reviews.csv',
encoding='utf-8',
on_bad_lines='skip' # Ignorer les lignes mal formées au lieu de crasher
)
# Si vous avez besoin de supprimer les emojis (ce que j'ai pas fait) :
import re
df['review_text'] = df['review_text'].apply(
lambda x: re.sub(r'[^\x00-\x7F]+', '', str(x))
)
df.to_csv('cleaned_reviews.csv', index=False, encoding='utf-8')
Engagez-vous à utiliser UTF-8 partout. Base de données, CSV, réponses API, logs. Fini le mélange d’encodages parce que vos données legacy avaient une bizarrerie de 2019.
J’ai aussi commencé à logger les progrès agressivement—chaque 1 000 lignes—donc si quelque chose casse à nouveau, je sais exactement où sans avoir à éplucher manuellement les CSVs. Ça seul aurait réduit mon temps de debugging de 48 minutes à environ 8.
La vraie leçon (Spoiler : c’est pas sur les emojis)
Écoutez, l’histoire d’emoji, c’est une bonne anecdote. Tout le monde adore une bonne histoire de guerre « crashé par emoji ». Mais le vrai problème ici, c’est la discipline de test.
J’ai testé avec 500 lignes propres et aseptisées. La production contenait 10 000 lignes avec du vrai chaos : des
