Retour — 03 Software Engineering
Ipsos — refonte du moteur d'export Excel
Un export financier qui crashait au-delà de 50 000 lignes, réécrit en streaming pur : de 3–4 Go de mémoire à 100–200 Mo.
Contexte
Portail financier interne en C# / ASP.NET, hébergé sur IIS avec SQL Server, utilisé par les contrôleurs de gestion de plus de 90 pays. Équipe répartie entre l'Europe, l'Amérique du Nord et l'Inde ; travail en anglais, Jira, cadence agile.
Le moteur d'export Excel tombait en OutOfMemoryException dès que le
rapport dépassait 50 000 lignes. Les utilisateurs contournaient en découpant leurs
exports à la main — quand ils y pensaient.
Diagnostic
La V1 chargeait l'intégralité du résultat SQL dans une DataTable, puis
laissait EPPlus construire le classeur en mémoire. La donnée existait donc deux fois, et
les gros tableaux de chaînes partaient directement sur le Large Object Heap, qui se
fragmente et ne se compacte pas.
3 à 4 Go de mémoire consommés pour 50 Mo de données réelles. Crash à 45 s sur les plus gros rapports.
La refonte
Réécriture en streaming pur : plus aucune matérialisation complète du jeu de données en mémoire.
- Open XML SDK en mode SAX — les lignes sont écrites au fil de l'eau au lieu d'être assemblées dans un arbre.
IDataReaderenSequentialAccess— la donnée est lue colonne par colonne depuis SQL Server, sans buffer intermédiaire.- Écriture directe sur
FileStream— le fichier se construit sur disque, pas en RAM. - Feuille de style unique indexée — les formats sont déclarés une fois et référencés, au lieu d'être recréés par cellule.
- Parsers sans allocation sur les chemins chauds, pour éviter de produire des millions d'objets temporaires.
- Auto-fit prédictif en deux passes — la largeur des colonnes est estimée pendant le streaming, sans relire le fichier.
- Recompression du
.xlsxen sortie.
Résultat
Mémoire stable à 100–200 Mo, quelle que soit la taille du rapport.
1 million de lignes exportées en ~2 minutes, là où la V1 crashait au bout de 45 secondes.
Les incidents OOM ont disparu des logs de production.
Fichiers 20 à 30 % plus légers après recompression.
Second chantier
Refactorisation d'un pipeline Python de prévision : robustesse face aux données dégradées, logs structurés exploitables en production, et encapsulation derrière une API pour découpler le pipeline de ses appelants.
Ce que j'en retire
Le gain n'est pas venu d'une micro-optimisation mais d'un changement de modèle : cesser de matérialiser. Et travailler en anglais dans une équipe répartie sur trois fuseaux apprend à écrire des tickets et des commits qui se suffisent à eux-mêmes, parce que personne ne sera disponible pour expliquer.