🔥 IA création de présentations : Palette (2026)
Découvrez l’IA création de présentations avec Palette IBM Research : modèle open weight, données synthétiques et génération de diapositives cohérentes pour votre design. Essayez !
Palette, ou comment apprendre à une IA à respecter votre style de présentation
Demandez à un grand modèle de langage de préparer une présentation, et vous aurez souvent quelque chose de « correct ». Demandez-lui d'en produire dix, et les mêmes choix visuels reviennent presque automatiquement : palettes prudentes, mise en page familière, titres et graphiques qui finissent par donner cette sensation de déjà -vu. Et si vous lui demandez de respecter votre charte, le problème devient plus concret : le modèle peut s'en écarter, alors que des documents confidentiels, eux, ne peuvent pas toujours être envoyés à un service externe.
C'est là qu'intervient Palette, un projet d'IBM Research présenté sur Hugging Face. L'idée n'est pas seulement d'écrire un prompt plus détaillé : l'équipe entraîne un modèle open weight de 20 milliards de paramètres pour générer des diapositives à partir d'un langage graphique défini. Surtout, ils séparent la conception éditoriale de la mise en page, apprennent au modèle à partir de présentations synthétiques et mettent en place un contrôle des fichiers avant de les livrer.
L'intérêt dépasse le diaporama « sorti de nulle part ». Palette propose une approche utile pour les entreprises qui veulent adapter une IA à leurs contraintes, sans perdre le contrôle sur leurs données et sur le rendu. Voici comment le système fonctionne, ce que montrent ses évaluations, et les limites à garder en tête avant d'envisager un usage en production.
Pourquoi une petite IA peine à créer de bonnes diapositives
Une présentation semble simple, parce que le résultat final vous est familier. Mais dès qu'on parle de diaporamas de dix ou vingt pages, le modèle doit jongler avec plusieurs choses à la fois : le contenu, la structure du récit et la place de chaque élément. Les trois sont liés, mais ils ne relèvent pas des mêmes compétences.
La géométrie ne se résume pas à écrire du code
Palette ne « dessine » pas directement les diapositives. Le modèle génère du code JavaScript avec la bibliothèque pptxgenjs, et ce code place les éléments à des coordonnées précises : position, largeur, hauteur, taille de police. Autrement dit : il doit anticiper le rendu visuel sans avoir la diapositive sous les yeux pendant l'écriture.
Un titre de 75 caractères n'occupe pas la même surface qu'un titre de 56 caractères, encore moins quand on change de taille de police. Selon la mise en forme, il peut passer sur plusieurs lignes, empiéter sur un graphique, ou tout simplement sortir de la page. Un modèle « petit » peut donc produire des textes tronqués, des éléments qui se superposent, ou des contrastes illisibles. Le souci n'est pas qu'il ne sait pas écrire : c'est qu'il doit raisonner sur un résultat visuel qu'il ne voit pas encore.
Le fond et la forme entrent en concurrence
Sur un diaporama complet, il faut aussi trancher quoi raconter et comment le représenter. Une série de chiffres mérite-t-elle un tableau ou un graphique ? Qu'est-ce qui doit devenir une diapositive à part ? Qu'est-ce qu'on condense pour éviter de noyer l'écran ?
Ce ne sont pas des « calculs » de placement : ce sont des décisions éditoriales. Les faire en une seule passe oblige le modèle à arbitrer entre plusieurs objectifs tout en gardant une cohérence visuelle. Et dans un contexte pro, cette cohérence compte : une présentation pour un comité de direction, pour des équipes commerciales ou pour des partenaires d'une entreprise du CAC 40 ne se construit pas avec les mêmes priorités.
Les exemples terminés n'expliquent pas les décisions
On trouve beaucoup de présentations finalisées, mais elles ne montrent généralement ni le plan initial, ni les arbitrages, ni le code qui a produit chaque page. Entraîner uniquement sur des exemples « propres » apprend à reproduire une apparence. Pas forcément à comprendre pourquoi un tableau a été remplacé par un graphique, ni ce qui a conduit à telle structure.
Palette cherche justement à combler ce manque. Le projet part d'un constat simple : quand le résultat peut être vérifié par un rendu et des règles géométriques, le modèle ne doit pas être seul juge. Il faut une chaîne qui sépare les décisions, puis qui contrôle le livrable.
Comment entraîner le modèle avec des données synthétiques
Pour apprendre à produire des présentations, le modèle a besoin d'exemples qui relient les consignes, les décisions de conception et le code final. Or, trouver un corpus public contenant tout ça ensemble est difficile. IBM Research a donc généré des données synthétiques à partir d'un grand modèle jouant le rôle d'enseignant.
Générer des présentations variées, pas une seule recette
Chaque présentation démarre par une « recette » : genre, longueur, types de mise en page, et directives de l'utilisateur. Les plans générés couvrent un éventail allant d'un canevas ordonné à du texte brut condensé. L'objectif est d'éviter que le modèle apprenne une seule mise en forme trop régulière.
Le projet rapporte environ 1 000 présentations synthétiques, soit près de 10 000 diapositives. Les exemples suivent le langage graphique d'IBM Design Language. Et c'est important : les résultats publiés ne prouvent pas que Palette adopte directement la charte de n'importe quelle entreprise. Ils montrent plutôt qu'on peut adapter un modèle à un langage visuel défini, à condition d'avoir des données cohérentes avec ce langage.
Apprendre les arbitrages, pas seulement le « bon » choix
Les exemples incluent aussi des explications contrefactuelles : le modèle indique une option envisagée puis explique pourquoi elle a été écartée. Pour des données trimestrielles, il peut par exemple justifier qu'un graphique est préférable à un tableau si le message central concerne la tendance, plutôt que la valeur exacte de chaque période.
Côté code, le raisonnement porte sur d'autres contraintes. Si un titre ne tient pas dans la taille prévue, le modèle peut justifier une réduction de la police pour préserver l'espace réservé au graphique. Ici, l'objectif est de transmettre des règles de décision - pas seulement une association entre une consigne et un résultat.
L'équipe note aussi un point de mise en œuvre utile : les exemples du rôle de codeur sont environ cinq fois plus longs que ceux du concepteur. Sans ajustement, un entraînement « naïf » déséquilibrerait l'apprentissage en faveur du codeur. Les exemples du concepteur ont donc été suréchantillonnés cinq fois.
Corriger le corpus avant de multiplier les consignes
Le modèle enseignant ne génère pas des données automatiquement « fiables ». Chaque présentation synthétique est rendue, puis contrôlée pour repérer les chevauchements et les débordements. Les diapositives défectueuses sont réparées, et le raisonnement est réécrit pour expliquer l'erreur et la correction.
Ils ont aussi rencontré un problème de fidélité aux sources : si le brief exige plus d'informations que ce qu'il contient réellement, le modèle peut inventer. Et il ne suffit pas toujours d'ajouter une règle dans le prompt. D'après leurs observations, les exemples de référence semblent influencer davantage le modèle que des consignes ajoutées après coup. Pour une entreprise, la conséquence est assez simple : la qualité des références et des données d'entraînement compte souvent plus qu'une longue liste d'instructions générales.
Pourquoi le contrĂ´le automatique est indispensable
Palette ne livre pas la première sortie « brute » du modèle. Chaque présentation passe par un mécanisme de vérification et de réparation, appelé harnais. L'idée : transformer certains défauts visuels en signaux mesurables, puis n'accepter une correction que si elle améliore réellement le rendu.
Détecter les défauts que le texte ne révèle pas
Au départ, le système applique des règles simples pour corriger certains problèmes connus, comme un code couleur mal formé qui pourrait rendre les diapositives noires. Ensuite, il génère le rendu des pages et mesure leur géométrie. Le contrôle repère notamment les textes qui se chevauchent, ceux qui sont coupés, ou ceux qui dépassent des limites de la diapositive.
Si une page est signalée, un modèle éditeur distinct peut réécrire le code. Par exemple, si des titres et des descriptions se superposent sur plusieurs cartes, l'éditeur peut réorganiser les cartes en grille. La correction passe alors par le même vérificateur.
N'accepter une réparation que si elle améliore le résultat
La règle la plus importante est aussi la plus pragmatique : la version corrigée n'est conservée que si les contrôles confirment une amélioration. Sinon, le système garde la version initiale. Résultat : le système peut réparer, mais il ne « dégrade silencieusement » le rendu au nom d'une correction supposée.
IBM Research rapporte un gain moyen de 3,5 points sur 131 présentations évaluées avec et sans harnais. Ce chiffre reflète l'effet du contrôle dans les conditions de l'expérience ; il ne garantit pas le même gain pour tous les documents ni toutes les chartes graphiques.
Ce que ce mécanisme change pour une entreprise
Pour des équipes qui produisent régulièrement des rapports, des présentations commerciales ou des supports internes, cette approche réduit une partie du travail répétitif de vérification. Elle ne remplace pas la validation du fond : un contrôle de débordement ne dit pas si un argument est juste, si une donnée est correctement interprétée, ni si la conclusion convient à un comité de direction.
Il faut donc distinguer contrôles automatiques et contrôles métier. Les premiers traitent des défauts mesurables ; les seconds restent du ressort de l'humain. Et dans un contexte européen, il faut aussi gérer séparément la confidentialité, les accès et la conformité au RGPD. Un modèle open weight peut faciliter un déploiement maîtrisé, mais il ne rend pas automatiquement un système conforme, ni les données automatiquement protégées.
Que montrent les résultats et quelles sont les limites
Palette a été évalué sur PresentBench, qui mesure cinq dimensions : fondamentaux, design visuel, exhaustivité, exactitude et fidélité. Le benchmark utilise des documents sources plutôt que des plans déjà prêts à l'emploi. Dans ces essais, un modèle de pointe distinct a d'abord transformé chaque document en plan, puis Palette a produit les diapositives.
Des performances solides sur deux domaines
Sur les trois domaines testés par IBM Research, Palette arrive en première position en économie et en éducation. Il se classe troisième pour les présentations de type discours, et obtient la deuxième place sur la moyenne des trois domaines. La moyenne est de 59,7 points, contre 60,8 pour NotebookLM, soit un écart de 1,1 point.
Ces résultats suggèrent qu'un modèle open weight de 20 milliards de paramètres peut être compétitif sur cette évaluation, surtout quand le contenu est bien structuré et que l'exactitude des données compte. Ils ne prouvent pas que Palette bat les modèles fermés partout. Les présentations narratives - plus orientées « prise de parole » - restent un point plus faible dans les résultats publiés.
Un benchmark ne dit pas tout
PresentBench évalue la qualité globale des diaporamas, sans mesurer directement l'alignement avec une charte graphique précise. Une présentation peut avoir une bonne note tout en utilisant une palette ou une typographie qui ne convient pas à l'organisation. IBM Research souligne aussi l'absence, à sa connaissance, d'un benchmark couvrant spécifiquement cette dimension.
Pour les entreprises, c'est une limite importante. Avant de déployer, il faudrait tester le système avec des présentations qui ressemblent vraiment à leurs usages : documents financiers, supports de formation, rapports pour la direction, ou présentations de vente. Il faudrait aussi vérifier la fidélité aux sources et estimer le temps réellement gagné - corrections humaines incluses.
Pour quels usages l'approche est-elle pertinente ?
Palette est surtout intéressant comme architecture et comme méthode. Il montre comment spécialiser un modèle, séparer planification et production, puis encadrer les sorties avec des contrôles techniques. Cette logique peut parler aux organisations qui veulent garder la main sur leur infrastructure ou éviter de transmettre des contenus sensibles à un service externe - à condition de mettre en place les protections nécessaires.
Le projet explore aussi d'autres pistes : utiliser les signaux du contrôle comme récompenses d'apprentissage, intégrer des figures extraites de documents, et adapter plus simplement le rendu à partir d'un ou deux fichiers PowerPoint existants. Là encore : ce sont des directions de travail, pas des capacités déjà démontrées dans les résultats publiés.
Ă€ retenir avant de lancer un projet similaire :
- Définissez d'abord les défauts que vous pouvez vérifier automatiquement.
- Séparez les décisions éditoriales des tâches de mise en page.
- Évaluez la fidélité aux sources en plus de l'apparence.
- Utilisez des exemples de référence représentatifs de votre langage graphique.
- Gardez une validation humaine pour le fond, les chiffres et les usages sensibles.
Conclusion : automatiser sans perdre la maîtrise
Le mérite de Palette ne tient pas à la promesse d'une présentation parfaite « en un clic ». Ce qui ressort, c'est une approche plus rigoureuse : clarifier le plan, confier le placement à une étape distincte, générer des exemples qui expliquent les choix et contrôler les sorties avant livraison.
Pour une équipe produit ou métier, la leçon est assez directe : isolez les tâches répétitives et les défauts qu'on peut mesurer, puis construisez un contrôle qui empêche une correction de dégrader le résultat. Ensuite seulement, testez sur vos propres documents, avec vos contraintes de confidentialité et vos critères de qualité. L'IA devient vraiment utile quand elle s'insère dans une chaîne contrôlable - pas quand on lui demande de remplacer le jugement qui manque au processus.
Comment Palette sépare le récit de la mise en page
Palette organise la création comme le ferait une équipe : une personne prépare le contenu et le plan, puis quelqu'un d'autre réalise les diapositives. Ici, ces deux rôles sont gérés par le même modèle, mais avec un module LoRA unique. Le but n'est pas de multiplier les modèles : c'est de séparer les tâches.
Le rĂ´le du concepteur : Ă©crire un brief exploitable
Le premier rôle transforme le document ou les consignes en un brief structuré au format JSON. Il fixe la palette de couleurs et le système typographique, puis décrit pour chaque diapositive le contenu exact, la mise en page et une justification de conception.
Concrètement, cette étape force à clarifier le récit avant de produire le code. Une diapositive peut être prévue comme une synthèse, un graphique ou une chronologie, avec une raison explicite. Et comme le brief reste modifiable, on peut ajuster une seule page sans demander au système de « reconstruire tout le diaporama ».
Le rĂ´le du codeur : dessiner une page Ă la fois
Le second rôle prend la spécification d'une diapositive et génère le code
pptxgenjscorrespondant, avec le raisonnement associé. Il n'a pas à gérer tout le récit en même temps qu'il place les éléments : le concepteur porte les choix éditoriaux, le codeur se concentre sur la réalisation.Comme le brief de chaque page existe déjà , les appels du codeur peuvent être lancés en parallèle. IBM Research indique que cette organisation accélère la phase de génération du code d'environ six à sept fois par rapport à un traitement séquentiel. Ce gain ne veut pas dire que la préparation, la vérification et la validation humaine disparaissent ; il concerne d'abord la fabrication du code et des pages.
Un découpage qui simplifie aussi le pilotage
Cette architecture aide une organisation, parce que les changements restent plus localisés. Si une équipe décide de remplacer une table par une chronologie, elle modifie le brief concerné plutôt que de régénérer l'ensemble. Et la logique est transposable : séparer la planification d'un livrable de sa production rend une chaîne d'IA plus facile à cadrer.
Cela dit, un brief structuré ne garantit pas un bon résultat. Si le brief est imprécis ou si le modèle lit mal une contrainte, le code peut quand même être défaillant. La séparation rend les erreurs plus simples à repérer et à corriger, mais elle ne les efface pas.