Générateur d'album de promotion
Yearbook
Générateur automatique d'album de promotion en Python : à partir d'un fichier d'étudiants et d'un dossier de photos, il produit les pages du yearbook (page de garde, photo de classe, trombinoscope), prêtes à imprimer.
Le projet
Une école qui réalise son album de promotion doit assembler à la main une soixantaine de fiches identiques : photo, nom, citation, mise en page, charte graphique. C'est long, répétitif, et une erreur de copier-coller passe inaperçue jusqu'à l'impression.
Ce script automatise toute la chaîne : on met à jour le fichier des étudiants, on relance, on récupère les pages. Ajouter un étudiant coûte une ligne de tableur au lieu d'une mise en page complète.
L'exercice imposait une contrainte forte : tout construire avec Pillow, sans moteur de mise en page. Chaque position devait donc être calculée en pixels, à la main.
Fonctionnalités
- Page de garde : logo et libellé de promotion positionnés relativement au format de page
- Page promotion : photo de classe redimensionnée en conservant son ratio, puis centrée
- Trombinoscope paginé en grille 5 × 2, avec pagination automatique par lots de dix étudiants
- Règles métier sur les photos : badges pour le délégué et son suppléant, floutage des étudiants ayant refusé le droit à l'image
- Options de rendu : orientation portrait ou paysage, noir et blanc, affichage des citations
Les difficultés rencontrées
J'avais écrit mon propre redimensionnement d'image, pixel par pixel, par plus proche voisin. Sur la page de garde (un seul logo), c'était instantané. Sur le trombinoscope, la génération devenait interminable : les pages font 3508 × 2480 pixels (A4 à 300 DPI pour l'impression) et il y a 26 photos à traiter, soit plusieurs millions d'itérations Python par image. Le goulot n'était pas l'algorithme : le plus proche voisin est le moins coûteux qui existe. C'était le fait que la boucle tourne en Python interprété plutôt qu'en code natif. Plutôt que de trancher entre les deux, j'ai séparé les usages : j'ai gardé mon implémentation là où elle a une valeur pédagogique et un coût nul, et j'ai délégué au redimensionnement natif de Pillow, écrit en C, pour le trombinoscope. Avec le recul, la vraie correction serait de fusionner les deux dans un seul module avec un paramètre de méthode, plutôt que de dupliquer le fichier.
Centrer du texte de largeur inconnue : Pillow ne sait pas centrer, il dessine à des coordonnées. J'ai dû mesurer chaque chaîne, calculer sa position, puis empiler les lignes de citation en cumulant leur hauteur réelle. Ça m'a fait comprendre tout ce qu'un moteur de mise en page fait pour nous sans qu'on le voie.
Ce que j'en ai retiré
- Un algorithme optimal peut rester lent si le langage qui l'exécute est le vrai coût. Avant d'optimiser, il faut savoir où le temps passe.
- Le traitement d'image bas niveau : espaces colorimétriques, gestion du canal alpha, conservation du ratio, DPI et dimensions d'impression.
- Le nettoyage de données réelles : les sources ne sont jamais dans le bon format. Ici un tableur, 26 fichiers texte séparés et un dossier de photos nommées par identifiant ; il a fallu tout réconcilier vers un fichier unique.
- La robustesse : chaque lecture et chaque sauvegarde est protégée avec un message explicite. Une photo manquante ne fait pas échouer les 25 autres pages.