Un parent a demandé à notre agent de transformer le rapport de science-fair d'un élève — un document Word sur un distributeur d'eau potable thermoélectrique — en présentation pour un concours d'innovation au niveau de la ville. Une vraie tâche, avec une vraie deadline et un vrai prof pour lire le résultat.
Le deck final était bien sorti — assez propre pour que la version éditable ait l'air aussi léchée que la version rendue et sophistiquée. Mais y arriver a cassé de quatre façons différentes, et chaque casse était le genre de bug qu'on ne trouve que quand quelqu'un télécharge vraiment le fichier et l'ouvre sur un PC portable d'école. Voici ce qui s'est passé, et ce que nous avons changé dans le système à cause de ça.
Casse n°1 : trois slides revenues vides
L'aperçu était parfait. Le HTML téléchargé, non — neuf images rendaient blanc.
La cause : le deck référençait les images par chemin relatif
(src="assets/chart.png"), ce qui se résout très bien dans l'aperçu de
l'espace de travail mais ne pointe nulle part une fois que le fichier .html voyage seul
jusqu'au dossier Téléchargements.
Le correctif qui compte n'est pas « embarquer les images » — c'est l'invariant : avant
qu'un deck soit déclaré livrable, grep -c 'src="assets/' doit renvoyer zéro.
Patcher les images une par une, c'est comme ça que la première tentative de correctif a
raté trois graphiques. Chaque règle de cette histoire finit pareil : boucler la boucle
avec un check, pas avec les yeux.
Casse n°2 : des graphiques qui n'existent qu'en ligne
Les bibliothèques de graphiques interactifs dessinent sur un canvas vivant. Dans le clone DOM en mode scroll de notre aperçu, les pixels peints disparaissent ; hors ligne, le script CDN n'arrive jamais. Pour un deck qui doit être projeté dans une salle de classe, « marche quand on est en ligne » ne suffit pas — les decks de présentation pré-rendent donc désormais les graphiques en PNG et les embarquent comme images. Les graphiques interactifs restent une option uniquement quand l'environnement est connu et que l'interaction est le but.
Casse n°3 : l'export qui ne passait pas
L'utilisateur voulait deux versions : un PPTX rendu et léché, et un éditable que l'élève pourrait retoucher avant de présenter. Le pipeline d'export éditable s'est révélé avoir une limite dure en entrée — un deck entièrement autonome est bien trop gros — et il lâchait aussi les images en chemin relatif et fusionnait mal les zones de texte. Le deck éditable a donc été reconstruit nativement avec python-pptx. Ce qui a fait remonter trois autres échecs du monde réel :
- Le calcul des tailles de police doit venir de la slide, pas de l'écran. Une slide 16:9 fait 960×540pt alors que le canvas de design fait 1920×1080px, donc
pt = px × 0.5— la conversion intuitive à 96dpi surdimensionne chaque run de texte de 50% et le texte se télescopait partout. - Le layout doit survivre à des métriques de police différentes. Les paires « gros chiffre + petite légende » s'alignaient parfaitement dans le navigateur et se chevauchaient dans WPS, dont les largeurs de glyphes diffèrent. Les empiler verticalement est immunisé ; côte à côte avec des décalages fixes, non.
- La géométrie a besoin d'un lint. Une image de couverture dépassait de 200px du bord de la slide — repérée par les yeux du parent, pas par le build. Chaque forme a désormais une assertion de limites avant la sauvegarde.
Casse n°4 : une vérification qui a cassé le livrable
Le script de QA a un jour déplacé le fichier fini en le validant — le check lui-même a
détruit la chose vérifiée. Deux leçons plus discrètes ont aussi survécu : les éditions de
texte en lot exigent une tolérance par élément plus un grep des restes, et
les chiffres des graphiques ne peuvent venir que des tableaux du document source —
jamais relus sur une petite capture d'écran, où 4.62 est un jour devenu 5.89.
Ce qui a changé dans le produit
Chacune de ces leçons est désormais une règle écrite dans le jeu de skills de l'agent — les mêmes skills que tout utilisateur reçoit. L'invariant d'état de livraison (zéro référence externe, vérifié par hash), les limites du pipeline d'export, les règles de géométrie et de layout python-pptx, les builds testés sur une slide avant le lot, et la boucle de QA qui rend chaque page avant de la remettre. Nous avons aussi gardé le compte rendu brut comme skill d'espace de travail, pour que les leçons d'un vrai projet se cumulent au lieu de s'évaporer.
C'est la partie de « l'IA fait des slides » que personne ne démontre : le fichier doit encore survivre au voyage jusqu'à un PC portable d'école, une installation WPS et un projecteur. L'écart entre « superbe en aperçu » et « s'ouvre correctement partout » est exactement là où vit le soin — et c'est pourquoi nous faisons passer de vraies tâches dans le produit nous-mêmes, en notant chaque casse.
Essaie le même pipeline toi-même sur Document to Slides — aperçu gratuit, tu ne paies que si tu veux le fichier propre.