J'ai demandé un PowerPoint à des agents : le premier, on voulait l'oublier ; le dernier, tout le monde l'a accepté

En bref — Le défi de départ : répondre en peu de temps à un appel d'offres avec un deck PowerPoint de qualité, sur le fond comme sur la forme. Du 8 au 28 octobre 2026, des agents ont construit ce deck, et la dernière version a été acceptée. Ce qui m'a permis d'intégrer les retours sans trembler, ce n'est pas un meilleur prompt : le deck est devenu des données qu'un script reconstruit sans coût en tokens, sous des gardes qui refusent d'abîmer ce qui est fini. Le rendu se regarde toujours à l'œil, et je termine par huit gestes à reprendre pour générer un PPT avec vos agents.

Ce que vous allez y trouver

Cet article raconte comment ce deck a été construit, de la première version qu'on voulait oublier à la dernière acceptée, et la méthode qui en est sortie. Il se lit seul : il s'appuie sur des actions décrites dans les articles précédents, et le chapitre 1 en résume l'essentiel. Je raconte d'abord les itérations, puis je décris la solution finale, puis j'en tire les leçons :

• Les itérations (chapitres 1 et 2) : le point de départ, ce qui rendait le sujet difficile et ce que cela a coûté en reprises.
• La solution finale (chapitres 3 et 4) : le dispositif d'agents tel qu'il tournait fin octobre, et le script qui reconstruit le deck à chaque version.
• Les leçons (chapitres 5 à 9) : ce qui a rendu les slides acceptables, ce qui a coincé en chemin, ce que je referais, et huit gestes à reprendre avec vos agents.

Le tournant : le 23 octobre, on a cessé de réécrire le deck

Au départ, chaque retour sur le deck repartait de zéro. Un agent écrivait un nouveau script de génération, le deck sortait en entier, puis le script était jeté : il y en a eu 113 jusqu'au 23 octobre. Chaque retour coûtait donc une génération complète, avec le risque d'abîmer ce qui était déjà juste.

Le 23 octobre, un générateur modulaire a pris le relais. Il reconstruit le deck à partir de la version précédente, et une nouvelle version n'est plus qu'une courte liste de modifications. C'est le vrai changement de cap du chantier : les gardes comme le rendu regardé à chaque itération reposent sur lui. Le chapitre 1 reprend l'histoire depuis le début.

Les chiffres viennent de commandes lancées sur l'historique git du projet ; ceux que je n'ai pas rejoués portent la mention « non rejoué ».

1. Le contexte

Un deck PowerPoint de réponse à un appel d'offres : démarche, convictions, profils, références. La charte est la charte interne de l'entreprise qui rédige l'offre, pas celle du client. Une première version a été générée de zéro par un agent le 9 octobre, puis rhabillée sur un modèle de proposition interne (dont le contenu d'origine n'est pas établi). Le nom du client n'est pas cité dans le texte, mais il reste visible dans les titres des slides montrées plus bas.

Je ne code toujours pas (voir « Je ne code pas, BMAD code pour moi avec ses agents : sur parole ou sur preuves ? ») : je décide ce que le deck doit dire, je regarde ce qui sort, je tranche. Le dispositif, les agents et les gardes ont été présentés dans « REX : des agents IA et des skills sur huit projets, nous gardons le volant et le fossé attendra ». Deux mots nouveaux seulement : le rendu est l'image réelle d'une slide telle que PowerPoint l'affiche ; un delta est une liste de modifications sur des slides précises, appliquée sans reconstruire tout le deck.

2. La complexité du sujet, avant même la technique

Le deck n'était pas un livrable de plus. Quatre choses s'y superposaient, et chacune obligeait à reprendre ce que les autres avaient réglé.

• Rapprocher le métier et l'IT. La demande du client vise à faire se parler deux mondes qui n'emploient pas les mêmes mots. Un même slide doit être lu par les deux.
• Une demande portée par l'IT. Elle ne vient pas du métier : le deck doit donc montrer la valeur côté métier sans que ce soit le métier qui l'ait formulée.
• Une transformation « data driven ». Le sujet lui-même demande de la démonstration : ce qu'on affirme doit pouvoir s'appuyer sur de la donnée.
• Des recommandations et une trajectoire pour le comex du client. Le lecteur final n'est ni l'IT ni le métier, c'est le comité exécutif : il faut conclure, ordonner, proposer un chemin.

Aucune de ces quatre exigences ne se traite par un paragraphe de plus. Chacune a déplacé le plan, donc des slides, donc des reprises.

Ce que cela a coûté en itérations, mesuré. Sur le dépôt du deck (lecture seule, mesuré le 30 octobre 2026) : 430 fichiers Python distincts ont été créés entre le 8 et le 28 octobre, dont 390 hors tests et 40 fichiers de tests ; 317 sont encore suivis par git à la fin. L'historique compte 79 commits sur la période. Les créations ne sont pas régulières : 70 le 8 octobre, puis 197 le 19 et 46 le 20, c'est-à-dire pendant la phase la plus intense de construction.

Ce chiffre mesure du travail produit, pas la qualité. Un script créé n'est pas une itération réussie, et plusieurs ont pu être écrits pour être jetés ; je n'ai pas compté lesquels (non mesuré).

3. La solution agentic sur laquelle le deck a été construit

Je l'ai lue dans le dépôt, sans relancer toute la chaîne.

La chaîne en cinq étapes. Les deux encadrés bleus sont les étapes qui refusent ou qui regardent.

Le principe : on ne régénère jamais un deck de zéro**.** Chaque version part de la précédente. Au début, un script de génération était recopié pour chaque version (j'y reviens). Depuis fin octobre, une nouvelle version est un delta : une courte liste d'opérations (remplacer un texte, ajuster une géométrie, ajouter une slide) appliquée à la dernière version, les slides étant désignées par leur titre exact. Simulation à blanc d'abord, environ 9 secondes, puis exécution réelle avec rendu image, environ 46 secondes.

Le déroulé d'une itération. Je dépose mes retours (un PPT corrigé, des commentaires) dans un dossier ; un déclencheur le détecte ; un lecteur des retours produit un rapport ; un agent rédige le delta ; simulation, exécution, rendu ; puis les vérifications (intégrité, rendu, charte, tests). Le statut final est « RENDU PRODUIT — À REGARDER ». Jamais « validé ». Je garde la main sur ce qu'aucun programme ne tranche : l'image du rendu, les marqueurs « [À …] » qui signalent une donnée manquante, les slides déclarées « finies » et les décisions d'architecture.

La solution agentic en un coup d'œil. Violet : agents qui consomment des tokens. Bleu : scripts à zéro token. Orange : l'humain. Le trait en pointillé est le comité de trois voix.

Les rôles sont ceux des articles précédents : relecteur du français, revue, test, comité de trois voix pour les choix importants (voir « Un agent ou un comité ? Ce que l'usage des comités m'a appris depuis leur mise en place »). Côté deck, quatre compétences réutilisables : construction, vérification du rendu, polissage des textes, bibliothèque de design. Le moteur vient d'un socle partagé que le projet ne modifie jamais ; le projet n'ajoute qu'une couche mince, livrée en petits lots prouvés par des tests de mutation (un test n'est accepté que si on l'a vu rouge en cassant volontairement le code).

Les tests, à trois niveaux. Mesurés une fois le 23 octobre sur la version finale du deck, sur une machine chargée (une exécution a duré 28 minutes sans cause connue : durées indicatives) :

• rapide, environ 3 minutes : les tests des scripts du deck seulement, avant de committer ;
• livraison, environ 3 minutes 30 : ajoute le rendu réel en PDF, avant de remettre un deck ;
• complet, environ 8 minutes 30 : tout, obligatoire quand le dispositif lui-même change.

Aucun test automatique ne voit un texte coupé : regarder l'image du rendu reste obligatoire, quel que soit le niveau.

Ce que les tests ont changé, mesuré. Mesuré a posteriori avec les règles d'aujourd'hui sur trois versions du deck, par des vérificateurs déterministes (aucun jugement de modèle) :

• 12 octobre : géométrie 1 violation sur 1 slide ; charte 9 types de défauts, 119 occurrences ; intégrité 2 erreurs de fichier.
• 20 octobre : géométrie 6 violations sur 6 slides ; charte 9 types, 27 occurrences ; intégrité 0.
• 23 octobre : géométrie 0 ; charte 0 ; intégrité 0.

Les tests sont passés de 32 fonctions dans 4 fichiers à 155 dans 22, surtout dans les derniers jours. Trois réserves. La version initiale était déjà presque propre (une forme hors slide) : la baisse est réelle mais petite. Les polices explicites sous 9 points ont augmenté (5,3 par slide, puis 12,3, puis 17,2) ; le vérificateur ne résout pas les tailles héritées de la mise en page : c'est un compromis de densité non résolu, pas un gain. Enfin, rien ne prouve que les tests ont causé la baisse (pas de comparaison contrôlée). Les tests ont rendu le défaut visible et empêché sa réapparition ; ils ne rendent pas le deck beau.

4. La construction d'un script modulaire

Le réflexe d'un agent à qui l'on demande un deck est d'écrire un script qui le génère. À chaque version, il en écrivait un nouveau : 113 scripts jetables, avec un plafond de 10 accepté le 15 octobre, que j'ai fini par purger. Ce n'est pas un défaut de l'agent, c'est ce que la consigne appelait.

Le 23 octobre, un générateur modulaire a pris leur place. Trois choix le définissent.

• Le contenu est déclaré, pas dessiné. Le plan du deck est un fichier de données ; le script le lit et construit les slides. Changer une slide, c'est changer une entrée du plan.
• Chaque version part de la précédente. Le script ne reconstruit pas tout de zéro : il applique à la dernière version une courte liste d'opérations (remplacer un texte, ajuster une géométrie, ajouter une slide), les slides étant désignées par leur titre exact.
• Le moteur n'est pas à moi. Il vient d'un socle partagé que le projet ne modifie jamais ; le projet n'ajoute qu'une couche mince, livrée en petits lots dont chaque test a été vu rouge d'abord, en cassant volontairement le code.

Le script ne coûte aucun token : c'est ce qui permet de le relancer à chaque retour. Ce que cela change dans la pratique, avec ses gardes, fait l'objet du chapitre 7.

5. Ce qui a servi à obtenir des slides jolies, et acceptées

Les tests du chapitre 3 disent qu'une forme ne sort pas de la page ; ils ne disent pas qu'une slide est belle. Ce qui a servi tient en cinq éléments, tous visibles dans le dépôt, aucun prouvé comme cause de l'acceptation (pas de comparaison contrôlée).

• Une charte posée d'avance. Le deck est habillé sur la charte interne de l'entreprise qui rédige l'offre, pas sur celle du client. Un vérificateur déterministe la contrôle à chaque version : 9 types de défauts le 12 octobre, 0 le 23.
• Une bibliothèque de design consultée avant de dessiner. Plutôt que d'inventer une forme par slide, l'agent choisit parmi des patterns catalogués par situation. C'est l'une des quatre compétences réutilisables citées plus haut ; une cinquième, de design de restitution, complète l'ensemble pour éviter le mur de cartes.
• Des textes polis par un outil dédié. Une compétence de polissage vise des titres qui énoncent une idée plutôt qu'une étiquette, et des puces resserrées.
• Le rendu regardé à l'œil, à chaque itération. Aucun test ne voit un texte coupé ; le statut « rendu produit, à regarder » m'oblige à ouvrir l'image. PowerPoint étant plus strict que LibreOffice, le rendu se fait aussi dans PowerPoint.
• Des retours intégrés un par un. Chaque retour devient un delta appliqué à la version précédente : on corrige ce qui est demandé sans toucher au reste, et le delta refuse de modifier une slide hors de sa liste.

Ce que je ne peux pas dire : lequel de ces éléments a pesé le plus. Je sais seulement que les défauts mesurables ont disparu et que la dernière version a été acceptée.

6. Ce qui a coincé

• 113 scripts jetables. À chaque version, un agent écrivait un nouveau script générateur. Il y en a eu 113, que j'ai fini par purger, avec un plafond de 10 accepté le 15 octobre.
• Le circuit de propagation des règles communes : une dizaine de commits d'entretien, entre le 9 et le 12 octobre, pour que le projet reçoive les règles du socle partagé. C'était lourd.
• Des gardes venues après la douleur. Un delta global a un jour modifié 42 slides, dont une finie, sans refuser. Un deck « généré sans erreur » n'avait en réalité pas été vérifié. L'empreinte d'origine du fichier ne voyait ni les notes, ni les sections, ni la mise en page. Et PowerPoint est plus strict que LibreOffice : un CV a été livré corrompu dans trois versions successives avant qu'on s'en aperçoive.

Aucune garde n'a été posée au départ. Je l'écris sans fierté : elles sont venues après.

7. Ce qui a marché, et ce que je referais

Écrire le deck comme des données**, construire par script.** Le 23 octobre, un générateur modulaire a pris le relais des scripts jetables. Il reconstruit le deck à partir de la version précédente. C'est ce qui rend une modification indolore : on change des entrées du plan, on relance, on regarde.

Un delta qui refuse. La commande de delta refuse d'écrire si le texte cherché n'est pas trouvé sur la slide visée, ou si une slide hors du delta a changé. J'ai rejoué ce mécanisme : régénération du deck par le script, puis comparaison slide par slide de l'empreinte du XML avec la version 5.117. Résultat : 71 slides sur 73 identiques à l'octet près ; 2 modifiées (la 11 et la 27) et une slide de test ajoutée (la 28). Cela montre combien un delta est petit, pas que le deck est meilleur, ni un gain de temps (non mesuré).

Cinq gardes qui disent non. Chacune empêche une erreur réelle déjà vécue :

• la vérification du rendu empêche des formes de sortir de la page et des textes de déborder ;
• le refus de toucher une slide « finie » protège ce que j'ai marqué comme terminé ;
• le refus de supprimer un marqueur « [À …] » sans source empêche qu'une donnée soit inventée pour boucher un trou ;
• l'empreinte du fichier empêche qu'un fichier modifié soit pris pour l'ancien parce que son nom est identique ;
• le refus d'un journal « succès » sans preuve de vérification empêche qu'un travail soit déclaré réussi sans avoir été vérifié.

Un statut qui ne ment pas. « Rendu produit, à regarder » plutôt que « validé ». C'est bête, et c'est ce qui m'a fait ouvrir les images à chaque itération.

Des tests rangés par niveau. Un niveau rapide, de l'ordre de quelques minutes, rend l'itération fréquente supportable ; sans lui, on retarde les vérifications. Des marqueurs de tests nommés par niveau suffisent à reprendre ce découpage ailleurs.

Le mécanisme reprend ailleurs. Mesuré sur un autre projet, non rejoué ici. Ce projet versionnait son deck en copiant un générateur de 1088 lignes qui redessine toutes les slides ; une tâche d'agent durait environ 56 min pour la V3 et 36 min pour la V5. Le delta y a été réutilisé : simulation à blanc 4,7 s, exécution réelle sans rendu 16,1 s, sortie de 35 slides, version précédente inchangée (somme md5 identique), 13 tests passés, 4 mutants chacun rendu rouge. Aucune comparaison de durée avec une régénération complète : pas de « x fois plus rapide ». Le delta convient aux retouches ciblées, pas aux grosses refontes.

Ce que je referais aussi : les règles des articles précédents, appliquées telles quelles. Celui qui écrit n'est pas celui qui juge, et ce qui peut se vérifier par un petit programme se vérifie par un petit programme (« Un agent ou un comité ? »). Je reconstruis avec un script à zéro token plutôt qu'avec un agent (« Mes agents lisaient trop : ce que dix semaines de chasse aux tokens m'ont appris »). Le coût total en tokens du chantier n'a pas été mesuré, mais d'après ses imports le script de construction n'en dépense pas.

Un incident m'a rappelé pourquoi relire le livrable : la version 5.117 contient encore une slide de test, la 28, intitulée « Slide de mesure générée… ». C'est un artefact de mesure oublié dans le livrable ; elle est à supprimer avant tout envoi.

8. Ce que j'en retiens

1. Figer le périmètre par écrit, et contrôler le texte contractuel par identité du texte. Une consigne dite une fois à un agent est oubliée à la session suivante. Je note ce qui ne bouge plus dans un fichier que l'agent lit. Pour les slides contractuelles, le contrôle compare le texte au caractère près, pas les octets du fichier, qui changent dès qu'on l'enregistre.
2. Partir d'une première version, puis l'habiller sur la charte interne. C'est ce que j'ai pratiqué ; je n'ai pas de preuve chiffrée que c'est mieux qu'une autre voie.
3. Les gardes arrivent après la douleur, mais autant les anticiper.

9. Si vous voulez générer un PPT avec vos agents

Huit gestes. Pour chacun : l'action, le résultat que vous pouvez montrer, et ce qu'il faut surveiller.

• Partez d'une première version générée, puis habillez-la sur votre charte. Action : faites générer une première version par l'agent, puis demandez-lui de la restyler sur votre modèle de proposition interne, sans toucher au fond. Résultat montrable : le même contenu, dans la charte. À surveiller : un agent qui « améliore » les slides existantes sans qu'on le lui ait demandé.
• Écrivez le deck comme des données, pas comme de la géométrie. Action : un fichier de plan avec, par slide, un titre, des puces et un type de mise en page ; l'agent n'écrit que cela. Résultat montrable : le fichier de plan. À surveiller : un agent qui place des formes à la main, signe que la consigne a glissé.
• Faites construire par un script. Action : un script (Python) qui part de la version précédente et ne régénère que ce qui est demandé. Résultat montrable : le même script relancé deux fois, avec la liste des slides qui ont changé. À surveiller : le script qui se réécrit à chaque version (j'ai eu 113 scripts) ; plafonnez-les. Pour des retouches ciblées, un petit fichier d'opérations, slides désignées par titre exact ; titre ambigu, absent ou simple préfixe : refusez.
• Posez des gardes qui refusent. Action : refuser l'écriture si une slide « finie » a bougé, si un texte cherché n'est pas trouvé, si un marqueur « [À confirmer] » disparaît sans source. Résultat montrable : un refus affiché, sur un cas que vous avez provoqué exprès. À surveiller : une garde que vous n'avez jamais vue refuser n'est pas éprouvée.
• Écrivez la liste « on ne touche plus ». Action : une ligne par élément figé, dans un fichier lu par l'agent. Résultat montrable : la liste, datée. À surveiller : les consignes orales, qui s'évaporent d'une session à l'autre.
• Regardez chaque slide en image, et gardez un niveau de tests rapide. Action : exportez une image par slide et une planche-contact ; découpez vos tests en niveaux (rapide, livraison, complet). Résultat montrable : la planche, avec les défauts entourés. À surveiller : le rapport qui dit « validé » sans que personne ait regardé.

Planche-contact d'un deck synthétique (pas celui du client), produite par mon outil de planche-contact ; les deux défauts ont été injectés puis entourés par mes soins.

• Coupez quand le deck grossit sans raison. Action : relisez le plan, retirez les slides qui ne répondent pas au besoin (annexes, banque de slides). Résultat montrable : le nombre de slides avant et après, comme sur le graphique plus haut. À surveiller : ajouter ne coûte presque rien à l'agent ; le lecteur, lui, paie chaque slide.
• Nettoyez avant l'envoi. Action : cherchez les restes de mesure et de test dans le fichier final. Résultat montrable : la liste des slides, relue titre par titre. À surveiller : ma slide 28 de test, restée dans la version 5.117.

Conclusion

Mon deck n'a pas été accepté grâce à un prompt inspiré : il l'a été parce qu'on pouvait le modifier sans trembler. Un plan écrit comme des données, un script qui reconstruit pour zéro token, des gardes qui refusent de toucher à ce qui est fini, et un humain qui regarde l'image avant de dire oui. Le temps passé et la qualité face à un deck fait à la main n'ont pas été mesurés ; je ne fabrique pas de verdict. Mais si vous ne reprenez que deux gestes, prenez ceux-là : écrivez le deck comme des données, et regardez le rendu. C'est la méthode qui l'a fait.

Le prochain article, « Newton avait une pomme, moi un bouton : il permet d'utiliser jusqu'à dix agents et plus » , suivra une seule itération de bout en bout : qui passe la main à qui, entre agents, comité, petits programmes et mon arbitrage, schéma à l'appui. Promis, on y verra enfin qui fait quoi pendant que je bois mon café.

Note de l'auteur

Ce texte a été relu par un agent scribe pour l'orthographe, la syntaxe et la lisibilité ; le fond et la voix sont les miens.