# D6 · Repeatability and Improvement Documenter un workflow pour qu’un collègue puisse l’exécuter, versionner les prompts, mesurer la qualité et le temps de cycle, et itérer sur des preuves plutôt que sur le ressenti. import { Accordions, AccordionItem, Tabs, TabItem } from '@prosefly/astro-components'; Ce domaine pèse **14 %** de l’examen blanc — environ **7 items sur 50**. C’est là où « une chose que je fais » devient « une chose que notre équipe fait » : un workflow documenté pour que quelqu’un d’autre puisse l’exécuter, versionné pour que les changements soient traçables, mesuré pour savoir s’il est bon, et amélioré sur **preuves** plutôt que sur le *ressenti*. C’est l’aboutissement de toute la piste — décomposition, contrats, choix de capacité et supervision ne composent que si le workflow est répétable et s’améliore avec le temps. ## Ce qu’il faut savoir Un workflow répétable est un workflow qu’un collègue peut exécuter de bout en bout sans vous poser de question, parce qu’il est **documenté** (un runbook : déclencheur, étapes, entrées, sorties, points de revue, que faire en cas d’échec). Les prompts et les configurations sont **versionnés** — datés, avec une note de changement — pour que vous puissiez dire ce qui a changé et revenir en arrière si un changement empire les choses. La qualité et le **temps de cycle** sont **mesurés** contre les critères d’acceptation et l’horloge, pour que l’amélioration soit jugée sur des chiffres, pas sur le ressenti. L’itération est **fondée sur les preuves** : changer une seule chose, mesurer, la garder seulement si la métrique s’est améliorée. Le mode de défaillance est le workflow qui ne vit que dans la tête de l’auteur, change silencieusement, et est « amélioré » par intuition sans moyen de dire s’il est réellement devenu meilleur. ## Objectifs d’apprentissage À la fin de cette page, vous devriez être capable de : 1. **Documenter** un workflow en un runbook qu’un collègue peut exécuter sans vous. 2. **Versionner** les prompts et les configurations pour que les changements soient traçables et réversibles. 3. **Mesurer** un workflow sur la qualité (contre les critères d’acceptation) et le temps de cycle. 4. **Itérer** sur des preuves : changer une variable, mesurer, garder ou revenir en arrière. 5. **Reconnaître** l’« amélioration » fondée sur le ressenti et le goulot d’étranglement de l’auteur unique comme des anti-schémas. --- ## 6.1 Le runbook — documenter pour la transmission Un workflow que vous seul pouvez exécuter est un passif, pas un actif. Le test est brutal : **un collègue pourrait-il l’exécuter de bout en bout sans vous poser une seule question ?** Si non, il n’est pas répétable. Un runbook le rend tel. ```text RUNBOOK : Synthèse hebdomadaire des risques de deals DÉCLENCHEUR Lundi 09:00, ou à la demande ENTRÉES notes des commerciaux de la semaine ; export CRM ; (le Project détient guide de style + gabarit) ÉTAPES 1. Extraire les deals qui ont glissé (analyse de données sur l’export) 2. Tirer les dernières actualités par compte du top 5 (search) 3. Rédiger la synthèse dans le gabarit maison 4. Point de contrôle REVUE : vérifier que les chiffres se rapprochent, ton conforme à la marque SORTIE synthèse d’une page publiée sur #sales TERMINÉ synthèse publiée ; aucun chiffre non rapproché EN CAS D’ÉCHEC si export CRM manquant → le demander, ne pas estimer RESPONSABLE Sales Ops ; secours : Ops lead ``` | Élément du runbook | Pourquoi il doit être écrit | | --- | --- | | Déclencheur & entrées | Pour que l’exécutant sache quand et avec quoi | | Étapes (avec capacité) | Pour que l’exécutant reproduise le workflow, n’improvise pas | | Points de revue | Pour que la supervision survive à la transmission | | Définition de « terminé » | Pour que l’exécutant sache quand s’arrêter | | En cas d’échec | Pour que l’exécutant ne devine pas quand quelque chose manque | | Responsable & secours | Pour que le workflow ait un mainteneur | :::tip[Signal d’évaluation] « Un collègue doit l’exécuter pendant votre congé » ou « le workflow ne marche que quand vous le faites » demande de la documentation/un runbook. La bonne réponse écrit les étapes, les entrées, les points de revue et la gestion des échecs — pas « enregistre une vidéo de moi le faisant une fois » ni « ils se débrouilleront ». ::: ## 6.2 Versionner les prompts et la configuration Les prompts et les configurations de Project/GPT dérivent à mesure que vous les retouchez. Sans versionnage, vous ne pouvez répondre à deux questions essentielles : *qu’est-ce qui a changé ?* et *pouvons-nous revenir en arrière ?* | Pratique | Ce qu’elle vous apporte | | --- | --- | | Dater chaque version de prompt | Vous savez quelle version a produit quels résultats | | Écrire une note de changement d’une ligne | Vous savez *pourquoi* elle a changé | | Garder la version précédente | Vous pouvez revenir sur une régression | | Changer une seule chose par version | Vous pouvez attribuer l’effet au changement | **Exemple travaillé.** Un prompt de réponse de support est modifié pour « être plus concis ». Les réponses raccourcissent — et l’échantillon de satisfaction client baisse parce qu’elles omettent désormais une prochaine étape nécessaire. Parce que le changement était une unique version datée avec une note, vous revenez à la version précédente et changez ensuite *uniquement* la consigne de longueur tout en gardant l’instruction de prochaine étape. Sans versionnage, vous devineriez laquelle de plusieurs modifications a causé la baisse. :::tip[Signal d’évaluation] « Après plusieurs modifications, le workflow a empiré et personne ne sait pourquoi » est une défaillance de versionnage. La bonne réponse garde des versions datées avec des notes de changement et change une variable à la fois pour que les effets soient attribuables — pas « tout annuler et recommencer ». ::: ## 6.3 Mesurer la qualité Vous ne pouvez pas améliorer ce que vous ne mesurez pas, et « ça semble mieux » n’est pas une mesure. La qualité se mesure contre les **critères d’acceptation** de l’étape, issus du [Domaine 3](/fr/openai/applied-ai/domains/d3-inputs-outputs-and-contracts/). | Signal de qualité | Comment le mesurer | | --- | --- | | Justesse | Taux d’erreur échantillonné contre les critères d’acceptation | | Complétude | Fraction des sorties satisfaisant toute la check-list | | Taux de reprise | Fréquence à laquelle la sortie est éditée/rejetée au point de contrôle | | Plaintes en aval | Problèmes remontant au workflow | Le point de contrôle et l’échantillonnage du [Domaine 5](/fr/openai/applied-ai/domains/d5-review-points-and-human-oversight/) sont votre source de données : chaque item échantillonné est une mesure de qualité. Un workflow doté d’un régime d’échantillonnage a déjà une métrique de qualité — le taux d’erreur échantillonné — et il suffit de la suivre dans le temps. ## 6.4 Mesurer le temps de cycle La qualité est la moitié du tableau ; l’autre moitié est le **temps de cycle** — combien de temps le workflow prend de bout en bout, et quelle part de cela est humaine vs automatisée. Le mesurer vous dit où sont réellement la valeur (et le goulot d’étranglement). ```text Référence manuelle : ██████████████████████ 120 min/exécution (tout humain) Après workflow : ████ 20 min/exécution ── dont ── ██ 12 min automatisées ██ 8 min revue humaine ``` Deux usages : - **Justifier le workflow.** 120 → 20 minutes est le retour que vous avez passé au crible au [Domaine 1](/fr/openai/applied-ai/domains/d1-finding-and-scoping-opportunities/). - **Trouver la prochaine amélioration.** Si 8 des 20 minutes sont de la revue humaine, le plus grand levier restant est la conception de la revue (Domaine 5), pas un meilleur prompt. Mesurez avant d’optimiser, ou vous optimiserez la mauvaise étape. ## 6.5 Itérer sur des preuves, pas sur le ressenti L’amélioration est une boucle : hypothèse → changer *une* chose → mesurer contre la métrique → garder si mieux, revenir si non. L’amélioration au « ressenti » — changer plusieurs choses parce que la sortie « semble » meilleure — ne peut vous dire ce qui a aidé, ne peut être défendue, et empire souvent silencieusement les choses. ```text FONDÉE SUR LES PREUVES FONDÉE SUR LE RESSENTI (anti-schéma) 1 former une hypothèse 1 retoucher plusieurs choses d’un coup 2 changer UNE variable 2 lire quelques sorties 3 mesurer contre la métrique 3 « semble mieux », expédier 4 garder ou revenir sur le chiffre 4 aucune métrique, aucune attribution, aucun retour en arrière ``` | | Fondée sur les preuves | Fondée sur le ressenti | | --- | --- | --- | | Variables changées | Une à la fois | Plusieurs d’un coup | | Base de décision | La métrique mesurée | L’impression de quelques sorties | | Réversible ? | Oui — versionnée | Non — non suivie | | Apprend avec le temps ? | Oui | Non | :::tip[Signal d’évaluation] « Nous avons changé le prompt et ça semble mieux » contre « nous avons fait un A/B d’un seul changement et le taux d’erreur est tombé de 9 % à 4 % » — l’examen récompense la réponse mesurée, à variable unique, attribuable, à chaque fois. ::: ## 6.6 Boucler avec les autres domaines La répétabilité est là où les pièces de la piste se connectent : les **critères** d’acceptation (D3) sont la métrique de qualité ; l’**échantillonnage** de revue (D5) est la source de données ; le **runbook** documente la décomposition (D2) et les choix de capacité (D4) ; et le retour mesuré valide l’**opportunité** que vous avez cadrée (D1). Un workflow documenté, versionné, mesuré et itéré est le produit fini que tout le cours Applied AI vous apprend à construire — et c’est ce qu’un collègue peut exécuter, qu’un manager peut approuver, et que vous pouvez continuer à améliorer sans deviner. --- ## Cadre de décision **La boucle DRIVE** — le cycle de maintenance d’un workflow en production. | Lettre | Étape | Ce que vous faites | | --- | --- | --- | | **D** — Document | Runbook | L’écrire pour qu’un collègue l’exécute sans vous demander | | **R** — Record versions | Contrôle de version | Dater chaque changement de prompt/config avec une note d’une ligne | | **I** — Instrument | Mesurer | Suivre la qualité (vs critères d’acceptation) et le temps de cycle | | **V** — Vary one thing | Itérer | Changer une seule variable par expérience | | **E** — Evaluate | Décider | La garder si la métrique s’est améliorée ; revenir si non | Exécutez **DRIVE** chaque fois que le workflow est en production et en cours d’amélioration. La discipline est dans **V** et **E** : un changement, mesuré, gardé ou annulé sur le chiffre — jamais un paquet de retouches jugé au ressenti. ## Erreurs fréquentes | Erreur | Pourquoi elle se produit | Que faire à la place | | --- | --- | --- | | Le workflow ne vit que dans la tête de l’auteur | Il marche quand l’auteur l’exécute | Écrire un runbook qu’un collègue peut exécuter sans aide | | Aucun versionnage de prompt/config | Éditer sur place est plus rapide | Dater les versions, noter le changement, garder la version précédente | | Changer plusieurs choses puis juger au ressenti | Cela paraît efficace | Changer une variable, mesurer contre la métrique | | « Ça semble mieux » comme test d’amélioration | Le ressenti est facile | Mesurer taux d’erreur / reprise / temps de cycle ; décider sur le chiffre | | Aucune mesure du temps de cycle | Seule la qualité paraît importante | Mesurer le temps de bout en bout pour trouver le vrai goulot d’étranglement | | Optimiser le prompt quand la revue est le goulot | Le prompting est le levier familier | Mesurer d’abord ; optimiser l’étape qui coûte réellement du temps | | Aucune définition de « terminé » dans le runbook | L’auteur « sait juste » | Écrire la condition de « terminé » pour que l’exécutant sache quand s’arrêter | | Aucun chemin de retour après un mauvais changement | Le versionnage a été sauté | Garder les versions précédentes pour qu’une régression puisse être annulée | ## Mise en situation **Situation.** Sofia a construit un workflow de revue de contrats qui signale les clauses risquées et rédige une note de synthèse. Il lui fait gagner environ 90 minutes par contrat et elle en est fière. Trois choses tournent désormais mal. D’abord, elle part en congé et son secours ne peut pas l’exécuter — il existe comme un ensemble de prompts que Sofia a « en tête » et colle depuis un document de brouillon. Ensuite, le mois dernier, elle a modifié le prompt de signalement « un bon nombre de fois » pour attraper plus de types de clauses, et dernièrement il signale bien plus de faux positifs, mais elle ne peut pas dire quelle modification l’a causé. Enfin, son manager demande « est-ce réellement mieux qu’avant ? » et Sofia ne peut dire que cela « semble plus approfondi ». Elle veut continuer à régler le prompt jusqu’à ce qu’il « sonne juste ». **Trace de raisonnement expert.** 1. **Diagnostiquer les trois comme des défaillances de répétabilité, pas de qualité de prompt.** Le secours ne peut pas l’exécuter (lacune de documentation), la régression des faux positifs est intraçable (lacune de versionnage), et « semble plus approfondi » (lacune de mesure). Aucune n’est corrigée par plus de réglage de prompt ; le réglage au ressenti est précisément ce qui a créé la régression. 2. **Corriger la transmission avec un runbook.** Écrire le déclencheur, les entrées, les étapes ordonnées avec leurs capacités, le point de contrôle, la définition de « terminé », et que faire quand un contrat manque une section — pour que le secours l’exécute sans aide. « Enregistrer une vidéo » ou « ils se débrouilleront » échoue au test sans-question. 3. **Introduire le versionnage pour isoler la régression.** Les faux positifs sont apparus après « un bon nombre de » modifications non datées, donc il n’y a aucun moyen d’attribuer ou de revenir en arrière. Adopter des versions datées avec des notes de changement d’une ligne, restaurer la dernière version connue pour avoir un faible taux de faux positifs, puis réappliquer les ajouts *individuels* de types de clauses un à la fois, en mesurant après chacun, pour trouver la modification qui a introduit le bruit. 4. **Instrumenter la qualité et le temps de cycle.** Définir les critères d’acceptation (quels types de clauses doivent être signalés ; taux de faux positifs acceptable) et mesurer le taux d’erreur/faux positifs échantillonné et le temps de bout en bout. Désormais « est-ce mieux ? » a une réponse : un chiffre, avant et après, contre une référence. 5. **Passer à l’itération fondée sur les preuves.** Remplacer « régler jusqu’à ce que ça sonne juste » par la boucle DRIVE : émettre une hypothèse, changer une règle de type de clause, mesurer le taux de faux positifs sur un échantillon fixe, garder ou revenir. Cela corrige à la fois la régression actuelle et prévient la suivante. 6. **Répondre correctement au manager.** Non pas « ça semble plus approfondi » mais « sur un échantillon de 40 contrats, il signale 96 % des types de clauses cibles (la référence était manuelle) à un taux de faux positifs de 8 %, en baisse depuis 19 % la semaine dernière après annulation de la mauvaise modification, et réduit le temps de revue de ~110 à ~20 minutes ». **La décision :** traiter les problèmes comme des lacunes de documentation, de versionnage et de mesure — écrire le **runbook**, adopter un **versionnage daté un-changement-à-la-fois** pour isoler et annuler la régression, et **instrumenter la qualité et le temps de cycle** pour que l’itération soit fondée sur les preuves — pas « continuer à régler jusqu’à ce que ça sonne juste », qui est l’anti-schéma du ressenti ayant causé la régression au départ. ## Pièges de l’évaluation | Piège | Pourquoi c’est tentant | Le discriminant | | --- | --- | --- | | « Enregistrer une vidéo de moi le faisant » comme documentation | Cela capte les étapes vaguement | Un runbook (étapes, entrées, revue, terminé, gestion des échecs) est ce qui permet à un collègue de l’exécuter sans aide | | « Continuer à régler le prompt jusqu’à ce que ça sonne juste » | L’itération paraît un progrès | L’itération au ressenti ne peut ni attribuer ni mesurer ; changer une chose et mesurer | | « Ça semble plus approfondi » comme preuve d’amélioration | Les impressions sont immédiates | L’amélioration doit être montrée contre une métrique (taux d’erreur, reprise, temps de cycle) | | « Tout annuler et recommencer » après une régression | Cela paraît une page blanche | Le versionnage permet de revenir à la dernière bonne version et de réappliquer les changements un à la fois | | « Optimiser le prompt » quand la revue est le goulot | Le prompting est le levier familier | Mesurer le temps de cycle d’abord ; optimiser l’étape qui coûte réellement le temps | | « L’auteur sait juste quand c’est terminé » | Ça marche pour l’auteur | Sans définition écrite de « terminé », le workflow ne peut être transmis | ## Questions d’entraînement Chaque item indique combien de réponses sélectionner. Décidez avant de dévoiler. A. Leur dire de se débrouiller à partir de l’historique du chat B. Écrire un runbook : déclencheur, entrées, étapes ordonnées avec capacités, points de revue, définition de « terminé », et gestion des échecs C. Enregistrer une vidéo rapide une fois et espérer qu’elle couvre tout D. Attendre votre retour **Réponse : B.** Un runbook écrit est ce qui permet à un collègue d’exécuter le workflow de bout en bout sans poser de question. « Se débrouiller » (A) et « attendre » (D) laissent le workflow inexécutable. Une vidéo ponctuelle (C) capte rarement de façon fiable les entrées, la gestion des échecs et la définition de « terminé ». A. Utiliser un modèle plus gros B. Le versionnage : des versions datées avec une note de changement d’une ligne, en changeant une variable à la fois C. Des prompts plus longs D. Relire chaque sortie **Réponse : B.** Des versions datées à changement unique rendent les effets attribuables et permettent le retour en arrière. Un modèle plus gros (A) et des prompts plus longs (C) ne traitent pas la traçabilité. Relire chaque sortie (D) attrape les erreurs mais n’attribue pas quelle modification les a causées. A. « Ça semble plus approfondi maintenant » B. « Sur un échantillon fixe de 40 items, le taux d’erreur est tombé de 19 % à 8 % et le temps de cycle de 110 à 20 minutes » C. « J’ai changé beaucoup de choses et j’aime plus la sortie » D. « Le nouveau prompt est plus long » **Réponse : B.** L’amélioration est montrée contre des métriques mesurées sur un échantillon fixe. « Semble plus approfondi » (A) et « je l’aime plus » (C) sont du ressenti. La longueur du prompt (D) n’est pas une mesure de qualité. A. Changer plusieurs choses d’un coup pour qu’il s’améliore plus vite B. Changer une variable, mesurer contre la métrique, la garder si mieux ou revenir si non C. Changer des choses jusqu’à ce que la sortie sonne juste D. Ne jamais changer un workflow qui marche **Réponse : B.** L’itération à variable unique, mesurée, garder-ou-revenir est ce qui rend l’amélioration attribuable et réversible. Changer plusieurs à la fois (A) et régler au ressenti (C) empêchent l’attribution. « Ne jamais changer » (D) renonce entièrement à l’amélioration. A. Rallonger le prompt B. Le plus grand levier restant est la conception de la revue, pas le prompt C. Passer à un modèle moins cher D. Rien d’utile **Réponse : B.** La mesure du temps de cycle localise le goulot d’étranglement ; la revue dominant, la conception de la revue est le levier, pas le prompting. La longueur du prompt (A) et le prix du modèle (C) ne touchent pas le temps de revue. La mesure est très utile (D). A. L’impression générale de l’auteur B. Les items échantillonnés du régime de revue, notés contre les critères d’acceptation C. Le nombre de mots du prompt D. Les notes de version du modèle **Réponse : B.** Le régime d’échantillonnage génère déjà des mesures de qualité lorsqu’il est noté contre les critères d’acceptation. L’impression de l’auteur (A) est du ressenti. La longueur du prompt (C) et les notes de version (D) ne sont pas des données de qualité. A. Réécrire tout le workflow de zéro B. Revenir à la version précédente, puis changer uniquement la consigne de longueur tout en gardant l’instruction de prochaine étape C. Garder la version concise ; la satisfaction se rétablira D. Ajouter plus de fichiers de connaissances **Réponse : B.** Le versionnage permet d’annuler la régression et de réappliquer un seul changement isolé. Recommencer (A) jette l’historique qui marchait. Garder une version qui a mesurablement nui à la satisfaction (C) n’est pas fondé sur les preuves. Les fichiers de connaissances (D) ne traitent pas la prochaine étape omise. A. Une définition de « terminé » B. L’opinion personnelle de l’auteur sur la sortie C. Que faire quand une entrée requise manque D. La date de coupure d’entraînement du modèle E. Le nombre de fois où l’auteur l’a exécuté **Réponse : A et C.** Une définition de « terminé » indique à l’exécutant quand s’arrêter, et la gestion des échecs lui indique quoi faire quand une entrée manque — toutes deux essentielles pour une exécution sans aide. L’opinion de l’auteur (B), la coupure d’entraînement (D) et un décompte d’exécutions (E) n’aident pas un collègue à l’exécuter. A. Rien — le temps est sans importance B. Elle quantifie le retour qui a justifié l’automatisation de l’opportunité et fournit une référence pour d’autres améliorations C. Elle prouve que la qualité de la sortie est élevée D. Elle règle la température du modèle **Réponse : B.** Les économies de temps de cycle quantifient le retour passé au crible au Domaine 1 et donnent une référence pour s’améliorer. Le temps est très pertinent (A). Elle ne prouve pas à elle seule la qualité (C) — cela nécessite la métrique des critères d’acceptation. Elle n’a rien à voir avec la température (D). A. Les améliorations ne peuvent être attribuées à aucun changement spécifique B. Il n’y a aucun moyen de dire si le workflow est réellement devenu meilleur C. Le modèle devient physiquement plus lent D. La tarification en tokens augmente E. Le workflow se documente automatiquement **Réponse : A et B.** La retouche multi-variables sans métrique empêche l’attribution et ne peut démontrer une amélioration réelle — l’anti-schéma du ressenti. Elle ne change pas la vitesse du modèle (C) ni la tarification en tokens (D), et elle ne s’auto-documente certainement pas (E). A. Ils ne le font pas ; la répétabilité est indépendante B. Les critères d’acceptation (D3) sont la métrique de qualité, l’échantillonnage de revue (D5) est la source de données, et le runbook documente la décomposition (D2) et les choix de capacité (D4) C. Seul le choix du modèle compte D. Seule la formulation du prompt compte **Réponse : B.** La répétabilité connecte la piste : les critères fournissent la métrique, l’échantillonnage fournit les données, et le runbook enregistre la décomposition et les capacités. Elle n’est pas indépendante (A). Le choix du modèle (C) et la formulation du prompt (D) seuls ne rendent pas un workflow mesurable et prêt à être transmis. A. Supprimer le workflow et le reconstruire de mémoire B. Restaurer la dernière version avec un faible taux de faux positifs, puis réappliquer les changements individuels un à la fois, en mesurant après chacun C. Garder toutes les modifications et baisser la température D. Ajouter plus de types de clauses pour submerger les faux positifs **Réponse : B.** Revenir à une version connue comme bonne et réappliquer les changements un à la fois avec mesure isole la modification fautive et restaure la qualité. Reconstruire de mémoire (A) perd l’historique qui marchait. Garder les modifications et changer la température (C) n’isole pas la cause. Ajouter plus de règles (D) aggrave le bruit. ## À retenir - Un workflow répétable est **documenté en un runbook** — déclencheur, étapes avec capacités, points de revue, définition de « terminé », gestion des échecs, responsable — pour qu’un collègue l’exécute sans vous poser de question. - **Versionner** les prompts et les configurations : les dater, noter le changement, garder la version précédente, changer une chose à la fois — pour que les effets soient attribuables et les régressions réversibles. - **Mesurer la qualité** contre les critères d’acceptation (en utilisant le régime d’échantillonnage comme source de données) et **mesurer le temps de cycle** pour trouver le vrai goulot d’étranglement. - **Itérer sur des preuves**, pas sur le ressenti : hypothèse → un changement → mesurer → garder ou revenir. « Ça semble mieux » n’est pas une mesure. - Mesurer **avant** d’optimiser, ou vous réglerez le prompt alors que l’étape de revue était le goulot d’étranglement. - La répétabilité **boucle la piste** : les critères D3 sont la métrique, l’échantillonnage D5 est la donnée, le runbook enregistre D2 et D4, et le retour en temps de cycle valide l’opportunité D1. - La **boucle DRIVE** — Document, Record versions, Instrument, Vary one thing, Evaluate — est le cycle de maintenance d’un workflow en production.